From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13981 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonathan Rajotte-Julien Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Date: Sat, 16 Mar 2019 10:28:19 -0400 Message-ID: <20190316142819.GE6994@joraj-alpa> References: <20190315210202.GD6994@joraj-alpa> <20190316022534.GN26605@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="50368"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.9.5 (2018-04-13) To: musl@lists.openwall.com, Michael Jeanson , Richard Purdie , Mathieu Desnoyers Original-X-From: musl-return-13997-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 16 15:28:36 2019 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.89) (envelope-from ) id 1h5AId-000Czv-B8 for gllmg-musl@m.gmane.org; Sat, 16 Mar 2019 15:28:35 +0100 Original-Received: (qmail 32244 invoked by uid 550); 16 Mar 2019 14:28:32 -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 32226 invoked from network); 16 Mar 2019 14:28:32 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 506F7A644C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1552746500; bh=I0KC6Df95k7s9xmlXFMampwBJAjLOGvPycsHeXuXAVM=; h=Date:From:To:Message-ID:MIME-Version; b=JrvL0su3JAtxS0GE2NVEb7q12AofVtRWYn5ju11JKwP7C9FVl9M0m06I3hTNeBqLs jL+pRk4Y75myLMjIbqph1buqGwCmZWs0DPwRPaGtoQMZjKNnINo/Ct6qK8qBaBY7oK jPVtoYzoWtvhLBYRo9v7yy4/AZNYNMCZ3Flht7NBMoJPVCUWXQqYlJbc+44eEn/wNH E2Lwa5i5PWmlBLSdzZsSzulGzbPB1TKjX51byWoeoXsYEFLs/P010F+GxWGVdgeH6M j5BrrB3wv5FoBN0Nmz1AXYV44SbTOX/kVs2oDMZBSuEMXke2XAuyPGO2etnSUNjcJq 36CqYvnnNjjXg== X-Virus-Scanned: amavisd-new at efficios.com Content-Disposition: inline In-Reply-To: <20190316022534.GN26605@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:13981 Archived-At: > > A simple command line to show this: > > > > taskset -c 0 nproc --all > > > > This is equivalent to asking sysconf(__SC_NPROCESSORS_CONF). > > the right way to check the sysconf from a shell is getconf It was only to provide an easy reproducer. But you are right in that nproc does not expose the complete picture. Thanks for taking the time to reproduce the base problem. I mixed up the _NPROCESSORS_ONLN result for glibc, it should have been 4 in the previous email since there is 4 online cpu even if we have sched_affinity only set for cpu0. (nproc was not proving my point for the _NPROCESSORS_ONLN value) As you know, you can take a cpu offline easily, but we still need to account for it in userspace tracing since it can be put back online (see Mathieu Desnoyers answer in this thread). echo 0 > /sys/devices/system/cpu/cpu3/online Now on a glibc system: $ taskset -c 0 getconf -a |grep NPROC _NPROCESSORS_CONF 4 _NPROCESSORS_ONLN 3 This is why we use _NPROCESSORS_CONF and expect it to represent the complete picture. We do not care much for _NPROCESSORS_ONLN or affinity. This is why the use of "nproc --all" was sufficient for me (I was wrong). > > on glibc system > $ taskset -c 0 getconf -a |grep NPROC > _NPROCESSORS_CONF 8 > _NPROCESSORS_ONLN 8 > > on musl > $ taskset -c 0 getconf -a |grep NPROC > _NPROCESSORS_CONF 1 > _NPROCESSORS_ONLN 1 > > so both values differ (plain nproc returns the affinity number, > *_ONLN is all the cpus that the kernel schedules to, *_CONF > includes offline cpus that may be hotplugged) > > these are documented linux extensions so i think musl should follow > the linux sysconf man page. (but the semantics is not entirely clear > e.g. there is /sys/devices/system/cpu/possible which can have larger > number than echo /sys/devices/system/cpu/cpu[0-9]* |wc -w which is > what glibc seems to be doing for *_CONF) > > i think we need to know why does a process care if musl returns > the wrong number? or what are the valid uses of such a number? > (there are heterogeous systems like arm big-little, numa systems > with many sockets, containers, virtualization,.. how deep may a > user process need to go down in this rabbit hole?) I'll refer you to Mathieu Desnoyers answer regarding that. (same thread). It should be approved shortly by a moderator. Cheers -- Jonathan Rajotte-Julien EfficiOS