Re: [musl] [PATCH] sysconf: add _SC_NPROCESSORS_CONF support

[James Y Knight <jyknight@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

On Wed, May 5, 2021 at 10:05 AM Alexander Monakov <amonakov@ispras.ru>
wrote:

>
>
> 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.

[-- Attachment #2: Type: text/html, Size: 2851 bytes --]