From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs
Date: Fri, 5 Apr 2019 11:26:57 +0200 [thread overview]
Message-ID: <20190405092657.GD4038@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190404180230.GA14800@avx2>
On Thu, Apr 04, 2019 at 09:02:30PM +0300, Alexey Dobriyan wrote:
> On Thu, Apr 04, 2019 at 10:42:49AM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 03, 2019 at 11:08:09PM +0300, Alexey Dobriyan wrote:
> > > Currently there is no easy way to get the number of CPUs on the system.
> >
> > And this patch doesn't change that :-)
>
> It does! Application or a library could do one idempotent system call
> in a constructor.
You said: "get the number of CPUs on the system", but what this call
actually returns is: "size of CPU bitmask", these two things are
distinctly not the same.
> > The point is that nr_cpu_ids is the length of the bitmap, but does not
> > contain information on how many CPUs are in the system. Consider the
> > case where the bitmap is sparse.
>
> I understand that but how do you ship number of CPUs _and_ possible mask
> in one go?
You don't, possible mask is unrelated to number of CPUs and both are
unrelated to bitmap size.
In particular:
nr_cpus <= nr_possible_cpus <= nr_cpumask_bits
In absurdum an architecture could choose to iterate its CPUs as
1024*cpuid, just for giggles. Then suppose it has two sockets, and 16
CPUs per socket and only the second socket is populated.
The we get:
nr_cpumask_bits = 32k
nr_possible_cpus = 32
nr_cpus = 16
see what I mean?
Now, luckily we typically don't have crap like that, but I suspect that
with a little creative ACPI table magic we could actually get something
slightly less absurd but still non-trivial even on x86.
Also see how num_possible_cpus() is defined as
cpumask_weight(cpu_possible_mask), which is very much not nr_cpu_ids in
the generic case.
> > > Nobody seems to parse "/sys/devices/system/cpu/possible".
> > > Even if someone does, parsing sysfs is much slower than necessary.
> >
> > True; but I suppose glibc already does lots of that anyway, right? It
> > does contain the right information.
>
> sched_getaffinity(3) does sched_getaffinity(2) + memset()
>
> sysconf(_SC_NPROCESSORS_ONLN) does "/sys/devices/system/cpu/online"
>
> sysconf(_SC_NPROCESSORS_CONF) does readdir("/sys/devices/system/cpu")
> which is 5 syscalls. I'm not sure which cpumask readdir represents.
It counts the number of CPUs, which is strictly not the same as the
bitmap size.
next prev parent reply other threads:[~2019-04-05 9:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 20:08 [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs Alexey Dobriyan
2019-04-04 8:42 ` Peter Zijlstra
2019-04-04 18:02 ` Alexey Dobriyan
2019-04-05 9:26 ` Peter Zijlstra [this message]
2019-04-05 10:16 ` Florian Weimer
2019-04-05 11:04 ` Peter Zijlstra
2019-04-05 11:08 ` Florian Weimer
2019-04-05 11:49 ` Peter Zijlstra
2019-04-06 19:48 ` Alexey Dobriyan
2019-04-08 7:49 ` Florian Weimer
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=20190405092657.GD4038@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=adobriyan@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.