mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Samuel Holland <samuel@sholland.org>
Cc: musl@lists.openwall.com, jason <jason@insomnia247.nl>,
	vincent.donnefort@arm.com
Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support
Date: Sat, 10 Jul 2021 15:44:50 -0400	[thread overview]
Message-ID: <20210710194450.GX13220@brightrain.aerifal.cx> (raw)
In-Reply-To: <a1d89462-e8ec-88fc-4306-67aaa0967abc@sholland.org>

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.

> I looked through the procfs code for uses of for_each_possible_cpu and
> for_each_online_cpu, and the best candidates I found are:
>  - /proc/softirqs for _SC_NPROCESSORS_CONF. It was added in 2009
>    (commit d3d64df21d3d, v2.6.31). Its first line contains a column
>    for_each_possible_cpu.

This should be okay; nonstandard functionality like this does not need
to work back to ancient kernels. Maybe there's a way we could use the
kernel cpuset size (is that observable?) as a fallback -- or, if
kernels that old didn't have variable cpuset size, just default to
whatever the fixed size (1024?) was back then.

>  - /proc/stat for _SC_NPROCESSORS_ONLN. It has been around since
>    before git. It contains a line for_each_online_cpu.
> 
> Here's an example implementation:
> 
> diff --git a/src/conf/sysconf.c b/src/conf/sysconf.c
> index 3baaed32..8f787b81 100644
> --- a/src/conf/sysconf.c
> +++ b/src/conf/sysconf.c
> @@ -193,10 +193,27 @@ long sysconf(int name)
>  		return SEM_VALUE_MAX;
>  	case JT_DELAYTIMER_MAX & 255:
>  		return DELAYTIMER_MAX;
> -	case JT_NPROCESSORS_CONF & 255:
> -	case JT_NPROCESSORS_ONLN & 255: ;
> +	case JT_NPROCESSORS_CONF & 255: ;
> +		FILE *f = fopen("/proc/softirqs", "rbe");
> +		int i, cnt = 0;
> +		if (f) {
> +			while (fscanf(f, " CPU%u", &i) > 0) ++cnt;
> +			fclose(f);
> +		}
> +		if (cnt)
> +			return cnt;
> +		/* fallthrough */

This is nice and simple, but the fscanf machinery is rather large and
undesirable to pull in as a linking consequence of sysconf. Likewise,
it should not be pulling in malloc/free. __fopen_rb_ca could be used
if we want to use stdio though, along with a trivial state machine to
count occurrances of "CPU" in first line.

> +	case JT_NPROCESSORS_ONLN & 255:
> +		f = fopen("/proc/stat", "rbe");
> +		cnt = 0;
> +		if (f) {
> +			fscanf(f, "cpu %*[^c]");
> +			while (fscanf(f, "cpu%u %*[^c]", &i) > 0) ++cnt;
> +			fclose(f);
> +		}
> +		if (cnt)
> +			return cnt;
>  		unsigned char set[128] = {1};
> -		int i, cnt;
>  		__syscall(SYS_sched_getaffinity, 0, sizeof set, set);
>  		for (i=cnt=0; i<sizeof set; i++)
>  			for (; set[i]; set[i]&=set[i]-1, cnt++);

Same principles here. fgets is a lot more suitable than fscanf here
anyway.

Rich

  reply	other threads:[~2021-07-10 19:45 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 [this message]
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
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:
  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=20210710194450.GX13220@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jason@insomnia247.nl \
    --cc=musl@lists.openwall.com \
    --cc=samuel@sholland.org \
    --cc=vincent.donnefort@arm.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).