From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12794 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Some questions Date: Tue, 1 May 2018 17:03:30 -0400 Message-ID: <20180501210330.GU1392@brightrain.aerifal.cx> References: <20180430031653.GI1392@brightrain.aerifal.cx> <20180430153555.GM1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1525208522 4695 195.159.176.226 (1 May 2018 21:02:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 May 2018 21:02:02 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Patrick Oppenlander Original-X-From: musl-return-12810-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 01 23:01:57 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fDcPM-00012c-Hy for gllmg-musl@m.gmane.org; Tue, 01 May 2018 23:01:56 +0200 Original-Received: (qmail 7958 invoked by uid 550); 1 May 2018 21:03:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7907 invoked from network); 1 May 2018 21:03:58 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12794 Archived-At: On Tue, May 01, 2018 at 12:35:58PM +1000, Patrick Oppenlander wrote: > On Tue, May 1, 2018 at 1:35 AM, Rich Felker wrote: > > On Mon, Apr 30, 2018 at 01:55:16PM +1000, Patrick Oppenlander wrote: > >> I was talking about the case of a uniprocessor system running a multi > >> theaded process. > >> > >> In that case the "spin" part of spinlock just burns time & electrons. > >> The "lock" part obviously can't be omitted. Calling straight through > >> to the kernel is the most efficient thing to do. > > > > I see. Is this an issue you've actually hit? I don't see any obvious > > way to make this decision at runtime that doesn't incur unwanted costs > > or failure modes, and I suspect we're spinning way too many times > > anyway even for SMP (i.e. the ideal solution might just be > > significantly reducing the # of spins). > > I haven't measured the performance impact of it. > > One option could be to configure the number of spins at compile time > and set to zero for known uniprocessor architectures (like armv7m). Or > have a configure override. Really this is just performance tuning, > there's no danger of generating incorrect code. > > I can't find a way of detecting a SMP kernel other than parsing the > result of uname(2) which sucks. I was hoping there might be something > in auxv hwcap. There doesn't seem to be any good way. Unless you find this is a real performance bottleneck for you, I'd like to punt on it for now and come back when someone has time to do real research on number of spins that make sense and whether the number is low enough not to care for non-SMP. Rich