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

[Leah Neukirchen <leah@vuxu.org>]

Vincent Donnefort <vincent.donnefort@arm.com> writes:

>> > Moreover, in the case of a non-available sysfs, the fallback to sched_getaffinity
>> > would help and at least align _CONF with _ONL (which is the current behavior).
>> > 
>> > Reading /proc/stat and /proc/softirq looks like a hack. They just happen to
>> > align on the _ONL/_CONF and doesn't produce a machine-readable output. While
>> > the CPU sysfs subsys is really meant to describe CPUs.
>> 
>> If they're mandated stable interfaces that "happen" to have the exact
>> data we need, I don't see what the objection to using them is. A
>> better question would be whether access to them is restricted in any
>> hardening profiles. At least they don't seem to be hidden by the
>> hidepid mount option.
>> 
> Indeed the function hasn't changed for 10y, which is I guess somewhat stable
> and it is currently walking through all the possible CPUs (which is what we want
> to count). Also, this file is currently always present whenever procfs is
> mounted.
>
> Nonetheless, as this is human-readable, nothing mandates the format. And as an
> example, on my desktop machine, with 448 allocated CPUS, the first line of
> /proc/softirqs (the line that contains all the CPUs) is 4949 long. The
> "possible" mask describes same information with only 6 characters.

For the record, on my single-cpu mainboard with a "AMD Ryzen 7 3700X
8-Core Processor", there are 16 processor entries in /proc/cpuinfo,
but /proc/softirq goes to CPU31.  /sys/devices/system/cpu has entries
up to cpu15, and glibc getconf _NPROCESSORS_CONF also says 16.

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/