mailing list of musl libc
 help / color / mirror / Atom feed
From: Vincent Donnefort <>
To: Rich Felker <>
Cc: Samuel Holland <>,, jason <>
Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support
Date: Mon, 12 Jul 2021 19:12:10 +0100
Message-ID: <> (raw)
In-Reply-To: <>


> > > 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.
> It's not just a matter of age and de facto stability. Kernel policy is
> that the procfs files are stable interfaces. Despite being "human
> readable", they're also intended to be readable by, and actually read
> by, utilities such as the procps suite of tools, "top"-type programs,
> etc.

What I wanted to emphasis is the cost of reading that interface vs the CPU mask
in the sysfs. The only gain is for a system with a _CONF user, where some CPUs
have been hotunplug'ed, and where the sysfs isn't mounted while the procfs is.
This can surely happen, but compared with the cost of parsing a long string
(see the ~x1000 in the example above) it doesn't seem a good trade-off to me.

  reply	other threads:[~2021-07-12 18:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10  5:31 jason
2021-07-10 17:11 ` Rich Felker
2021-07-10 17:29 ` Samuel Holland
2021-07-10 19:44   ` Rich Felker
2021-07-12 13:08     ` Vincent Donnefort
2021-07-12 15:41       ` Rich Felker
2021-07-12 16:32         ` Vincent Donnefort
2021-07-12 17:14           ` Rich Felker
2021-07-12 18:12             ` Vincent Donnefort [this message]
2021-08-07 14:52             ` James Y Knight
2021-08-07 16:29           ` Leah Neukirchen
  -- strict thread matches above, loose matches on Subject: below --
2021-07-06  9:55 Vincent Donnefort

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:

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

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ \
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone