From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13980 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Date: Sat, 16 Mar 2019 03:25:34 +0100 Message-ID: <20190316022534.GN26605@port70.net> References: <20190315210202.GD6994@joraj-alpa> 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="173259"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Michael Jeanson , Richard Purdie , Mathieu Desnoyers , Jonathan Rajotte-Julien To: musl@lists.openwall.com Original-X-From: musl-return-13996-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 16 03:25:50 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 1h4z1B-000izW-S9 for gllmg-musl@m.gmane.org; Sat, 16 Mar 2019 03:25:49 +0100 Original-Received: (qmail 32135 invoked by uid 550); 16 Mar 2019 02:25: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 32114 invoked from network); 16 Mar 2019 02:25:46 -0000 Mail-Followup-To: musl@lists.openwall.com, Michael Jeanson , Richard Purdie , Mathieu Desnoyers , Jonathan Rajotte-Julien Content-Disposition: inline In-Reply-To: <20190315210202.GD6994@joraj-alpa> Xref: news.gmane.org gmane.linux.lib.musl.general:13980 Archived-At: * Jonathan Rajotte-Julien [2019-03-15 17:02:02 -0400]: > We are currently in the process of making sure that lttng [1] (linux tracer) run > smoothly on system using musl (Yocto, Alpine etc.). Most things work > fine. Still, we currently have tests that are failing due to an issue regarding > the reported number of configured processors on the system (__SC_NPROCESSORS_CONF). > Note that users of LTTng are also affected by this if they chose to modify the > sched affinity of their instrumented apps. This is relatively a big deal for us. > > Long story short, we start an app with "taskset -c 0" and we need to allocate > data structure internally but using the number of configured processors not the > number of online processors. To do so we call sysconf(__SC_NPROCESSORS_CONF). > Slight problem: the value returned is the _SC_NPROCESSORS_ONLN value instead of > __SC_NPROCESSORS_CONF. ... > 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 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?) note that most of /sys/devices/system/cpu/* is documented under Documentation/ABI/testing in linux, not in Documentation/ABI/stable and the format is not detailed, and some apis (e.g. /proc/cpuinfo) are known to be different on android (and grsec?) kernels it may be unmounted during early boot or in chroots, so sysfs parsing is only done when really necessary.