From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12797 Path: news.gmane.org!.POSTED!not-for-mail From: Patrick Oppenlander Newsgroups: gmane.linux.lib.musl.general Subject: Re: Some questions Date: Wed, 2 May 2018 08:14:33 +1000 Message-ID: References: <20180430031653.GI1392@brightrain.aerifal.cx> <20180430153555.GM1392@brightrain.aerifal.cx> <20180501210330.GU1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1525212762 14734 195.159.176.226 (1 May 2018 22:12:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 May 2018 22:12:42 +0000 (UTC) Cc: musl@lists.openwall.com Original-X-From: musl-return-12813-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 02 00:12:38 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 1fDdVm-0003kf-HJ for gllmg-musl@m.gmane.org; Wed, 02 May 2018 00:12:38 +0200 Original-Received: (qmail 32337 invoked by uid 550); 1 May 2018 22:14:47 -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 32318 invoked from network); 1 May 2018 22:14:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=3+2knVYccGiCThpOopqerhZ/r25KLhm66WbaNmmqA3Y=; b=n7ZbKbb6vZ4F02m+qDPmGPlTgt8+6g7EE5aWGMDjgcjNaWJQFQOk4JFAA8FsGcOF4N VQmSay0MS6G+OduBzb3HoDM1yrlkzJh6J6YS4G3rkZ/wHg5WCOUl+LgdzogRz2PxwyXt 5CuJzeCb23N4zQkkbUdz4qREQIT/HU3UTsm7TPnuwKt/0p3jWpPlemlb9PcbNXXhFdL8 lwVtymRlym2b5iKWr08zc7BxotVv7L0Wmq0cQTnNxKY+D07Mmst1na6lmRkyiGnZxKjK hwGYzqRD7GSGgg8++hAHwu5NZJSKCNycwsTCmRBBCLqeaaFtLgKlqeZ6RUoiZZ60aCU9 8xAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=3+2knVYccGiCThpOopqerhZ/r25KLhm66WbaNmmqA3Y=; b=b6AcGE8OOXYpW1zNpaQffOCuPJy+rrCCWRd+Y5cYsSIJNbcNex3ZrvTjaSVpiH9nva JpAqqTSWxYezNhOdQ38BLirwrSLrvvpV4q1yEUKhcLvwa+ydB+FSYq9N2iBzwjMQ9o+s xnBgz3mnLvLF1g5q9Bt5QuYLRU7GPVQAbASS6Cj4Uo+XXhFVqhlf3wTdkimYsVKb22NB PuNaNwD0ug4raXD/39BgOFjkn+kjAlGbhXGJQ9i1225zpC0YbLDqwBgY/9MRErJ/xC4q NCCKFYxBS58beotAOdHl9AQAUYWaQeAG5nq9SZN77Nqrk+/vZT7jRGwgS4izNFGxx3Mh hSLA== X-Gm-Message-State: ALQs6tDxj/QzTPPZVwlOUIs3IgPOEOcZpYWsFsT36zlHsfEiGwSjxpSi 3xi0WRymDCu+jbICUExi0ZEDp4XRGz5eCFRXIoJofA== X-Google-Smtp-Source: AB8JxZpC0tfqNz3UQHCBHZ4A3yVqZpIHabQUpSnlJkKzdThzHUz40WTioRQ5Eg2530smfvxn5IiSIa6/Iko4OUinCj0= X-Received: by 2002:a0c:bd9a:: with SMTP id n26-v6mr14407184qvg.141.1525212874230; Tue, 01 May 2018 15:14:34 -0700 (PDT) In-Reply-To: <20180501210330.GU1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12797 Archived-At: On Wed, May 2, 2018 at 7:03 AM, Rich Felker wrote: > 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. No problem. Patrick