mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] about sysconf(_SC_NPROCESSORS_CONF) issue
Date: Mon, 21 Nov 2022 21:34:26 +0100	[thread overview]
Message-ID: <20221121203426.GB2497@voyager> (raw)
In-Reply-To: <tencent_3DBB341679902FD1EDCC3D74EC07FE175606@qq.com>

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,&nbsp; and the musl implements this function by
> SYS_sched_getaffinity system call,&nbsp; 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:&nbsp;https://www.openwall.com/lists/musl/2021/05/05/,&nbsp; 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

      reply	other threads:[~2022-11-21 20:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  8:51 =?gb18030?B?zcPX09bt?=
2022-11-21 20:34 ` Markus Wichmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221121203426.GB2497@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).