[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221121203426.GB2497@voyager>
Date: Mon, 21 Nov 2022 21:34:26 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: about sysconf(_SC_NPROCESSORS_CONF) issue
On Mon, Nov 21, 2022 at 04:51:49PM +0800, 兔子猪 wrote:
> Hi
>
>
> currently, we use "sysconf(_SC_NPROCESSORS_CONF)" to get the number of
> the CPU, and the musl implements this function by
> SYS_sched_getaffinity system call, when some of CPUs are
> isolated, the return value is not correct.
>
Define "correct". That is actually the problem. See below.
>
> I have searched the history maillist of musl and found the same
> issue: https://www.openwall.com/lists/musl/2021/05/05/, but
> there is no final conclusion. I wonder why musl is doing this?
>
The problem is that the definition of that value is rather lacking.
Nobody really knows what the value is supposed to be, or what it could
be used for. At least for sysconf(_SC_NPROCESSORS_ONLN), we have a rough
idea, even though no conforming program could really tell the difference
between running on 16 processors and running on 1 processor. But _CONF?
_CONF could conceivably be the number of processors in the system, but
that is unstable under CPU hotplug. So maybe the maximum number of
processors the system can support? Or else the maximum number of
processors the kernel can support? The smaller of both? What about
disabled cores, do they count? And what would the value be used for?
We found one program that uses the value to get kernel CPU IDs, and
found that to be a bad use. That program should just have read
/proc/cpuinfo itself, then it could also have coped with non-contiguous
CPU IDs. Other than that, we could find no use of that value where the
value returned by musl was really wrong.
HTH,
Markus
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.
