Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 5 May 2021 13:20:47 -0400
From: James Y Knight <>
Cc: Vincent Donnefort <>
Subject: Re: [PATCH] sysconf: add _SC_NPROCESSORS_CONF support

On Wed, May 5, 2021 at 10:05 AM Alexander Monakov <>

> On Wed, 5 May 2021, Vincent Donnefort wrote:
> > Currently, _SC_NPROCESSORS_CONF is always equal to _SC_NPROCESSORS_ONLN.
> > However, it is expected from the first one to give the total number of
> CPUs
> > in the system, while the later must return only the number of CPUs which
> > are currently online. This distinction is important for a software such
> as
> > trace-cmd. Trace-cmd is a front-end for the kernel tracing tool ftrace.
> > When recording traces, trace-cmd needs to get the total number of CPUs
> > available in the system (_SC_NPROCESSORS_CONF) and not only the online
> ones
> > otherwise if a CPU goes offline some data might be missing.

BTW, it looks like what trace-cmd actually needs is the "largest cpu
id-number that could exist this boot" (as used by sched_getaffinity,
pthread_setaffinity_np, etc.) rather than "total number of CPUs which could
exist this boot".

Now, as far as I can tell _in practice_ the kernel always allocates
"possible" cpu ids contiguously (so /sys/devices/system/cpu/possible
will always contain e.g. "0-3", rather than something like "0,1,46,47"),
but the data structures don't appear to require that. It's stored and
reported as a bitmask. If Linux intends to guarantee that the "possible"
bitset is (and will always) remain contiguous from 0, then the "largest"
and "count" numbers are effectively equivalent, but otherwise they are not.

 > Hence, add a specific method to get _SC_NPROCESSORS_CONF, based on the
> > sysfs CPU entries /sys/devices/system/cpu/cpu[0-9]
> Why do the opendir instead of reading from
> /sys/devices/system/cpu/possible?
> The online/offline/possible CPU masks are documented in
> linux/Documentation/ABI/testing/sysfs-devices-system-cpu and
> linux/Documentation/cputopology.txt

The /sys/devices/system/cpu/cpuNN directories are created for every cpu in
the "possible" bitmask, so those should be equivalent. I expect the reason
glibc uses readdir is simply because "possible" was only introduced in
Linux 2.6.26 in 2008.

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.