Date: Wed, 5 May 2021 13:20:47 -0400 From: James Y Knight <jyknight@...gle.com> To: musl@...ts.openwall.com Cc: Vincent Donnefort <vincent.donnefort@....com> Subject: Re: [PATCH] sysconf: add _SC_NPROCESSORS_CONF support On Wed, May 5, 2021 at 10:05 AM Alexander Monakov <amonakov@...ras.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. 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.