[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210712130840.GA47550@e120877-lin.cambridge.arm.com>
Date: Mon, 12 Jul 2021 14:08:42 +0100
From: Vincent Donnefort <vincent.donnefort@....com>
To: Rich Felker <dalias@...c.org>
Cc: Samuel Holland <samuel@...lland.org>, musl@...ts.openwall.com,
jason <jason@...omnia247.nl>
Subject: Re: [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support
On Sat, Jul 10, 2021 at 03:44:50PM -0400, Rich Felker wrote:
> On Sat, Jul 10, 2021 at 12:29:34PM -0500, Samuel Holland wrote:
> > Hi all,
> >
> > While this topic is being discussed, I'd like to bring up another possible
> > method for consideration. It turns out that some files in procfs have contents
> > depending on the number of {possible,online} CPUs; we can parse them to get the
> > count we need.
> >
> > The benefits are:
> > - procfs is more likely to be mounted than sysfs, and it is already
> > documented as being required by musl.
> > - Some of the procfs interfaces have been around longer than the
> > sysfs interface.
> > - The parsing logic is somewhat simpler than for the files in
> > /sys/devices/system/cpu, because we are just counting the number
> > of occurrences of some string.
> >
> > The downsides are:
> > - It depends on the stability of the procfs file formats.
> > - The kernel uses more CPU to generate the contents of these files.
>
> My understanding is that the procfs files have stronger stability
> mandate than sysfs if anything (originally, only procfs was stable and
> sysfs was not). So I think it's perfectly acceptable to use and prefer
> procfs. And indeed it's more likely to be mounted; some
> container/sandbox setups I use bind-mount (or mount a new) procfs but
> do not expose any sysfs.
Only to cover the case where a user needs _CONF and doesn't have the sysfs
mounted, which is very unlikely, we are losing a lot. The masks, found in the
CPU subsystem are well documented, widely available, describe precisely the CPU
topology (which is what we want) and are "easy" to decode without fscanf.
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.
--
Vincent
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.
