From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13979
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Jonathan Rajotte-Julien <jonathan.rajotte-julien@efficios.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value
Date: Fri, 15 Mar 2019 17:02:02 -0400
Message-ID: <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="191315"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: Mutt/1.9.5 (2018-04-13)
Cc: Michael Jeanson <mjeanson@efficios.com>,
	Richard Purdie <richard.purdie@linuxfoundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: musl@lists.openwall.com
Original-X-From: musl-return-13995-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 15 22:02:19 2019
Return-path: <musl-return-13995-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-13995-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1h4ty6-000nfA-AM
	for gllmg-musl@m.gmane.org; Fri, 15 Mar 2019 22:02:18 +0100
Original-Received: (qmail 13370 invoked by uid 550); 15 Mar 2019 21:02:15 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 13333 invoked from network); 15 Mar 2019 21:02:14 -0000
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 6B6261C966E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com;
	s=default; t=1552683722;
	bh=hnxGfN8f983B5MYJtlqVJia1N1dFzTlU3MwjOr1MyP8=;
	h=Date:From:To:Message-ID:MIME-Version;
	b=UnYd0vVaYHpb7+z9SLEF5Ma6HG/QC6SnRF8GRftr3SBS5jte3kcoh3XNPZYCxqiKV
	 P1Gc9R14QE+k6Ey+JB4pvcdfNyeNahMcawfrbzwnROO1eE9f6C9xaZkN4O0szHBiwk
	 0+VLo/Il5mdcEt6B7okOH6Qq/UHwbDwP+5bo/MB8gUaLxk1L4yi9T+KpcMWXe+now9
	 OzAiLL1wUy1OO7WVd5w6V8RancAQWymDlSBXFX5qBEPGgs0mPGsC2ir64vCd+Va+/d
	 TnWrr21ME/pMmdV3y3CLfp8rSSMZw80NEFm1I27qKaExK3ZmuQ8GmqgjZkCzys0Z2D
	 mm1+IMx8grOHA==
X-Virus-Scanned: amavisd-new at efficios.com
Content-Disposition: inline
Xref: news.gmane.org gmane.linux.lib.musl.general:13979
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/13979>

Hi all,

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.

>From src/conf/sysconf.c:196

 case JT_NPROCESSORS_CONF & 255:
 case JT_NPROCESSORS_ONLN & 255: ;
   unsigned char set[128] = {1};
   int i, cnt;
   __syscall(SYS_sched_getaffinity, 0, sizeof set, set);
   for (i=cnt=0; i<sizeof set; i++)
     for (; set[i]; set[i]&=set[i]-1, cnt++);
   return cnt;

A simple command line to show this:

  taskset -c 0 nproc --all

This is equivalent to asking sysconf(__SC_NPROCESSORS_CONF).

On 4 cpu system using glibc:

  $ taskset -c 0 nproc --all
  4

On the same system using musl:

  $ taskset -c 0 nproc --all
  1

And as for _SC_NPROCESSORS_ONLN, we can use:

  taskset -c 0 nproc

Using glibc:
  $ taskset -c 0 nproc
  1

Using musl:
  $ taskset -c 0 nproc
  1

No problem there.

Not sure where to go from there. We will probably end-up having a fallback for
musl that will probably consist of parsing /sys/ like glibc does.

Still we wanted to get your feedback on the matter.

Cheers

-- 
Jonathan Rajotte-Julien
EfficiOS