linux-kernel - Re: getting processor numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Apr 2007 16:00:50 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Gautham R Shenoy <ego@...ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>, Paul Jackson <pj@....com>
Subject: Re: getting processor numbers

Andrew Morton wrote:
> Now it could be argued that the current behaviour is that sane thing: we
> allow the process to "pin" itself to not-present CPUs and just handle it in
> the CPU scheduler.

As a stop-gap solution Jakub will likely implement the sched_getaffinity
hack.  So, it would realy be best to get the masks updated.

But all this of course does not solve the issue sysconf() has.  In
sysconf we cannot use sched_getaffinity since all the systems CPUs must
be reported.

> Is it kernel overhead, or userspace?  The overhead of counting the bits?

The overhead I meant is userland.

> Because sched_getaffinity() could be easily sped up in the case where
> it is operating on the current process.

If there is possibility to treat this case special and make it faster,
please do so.  It would be best to allow pid==0 as a special case so
that callers don't have to find out the TID (which they shouldn't have
to know).

> Anyway, where do we stand?  Assuming we can address the CPU hotplug issues,
> does sched_getaffinity() look like it will be suitable?

It's only usable for the special case on the OpenMP code where the
number of threads is used to determine the number of worker threads.
For sysconf() we still need better support.  Maybe now somebody will
step up and say they need faster sysconf as well.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)