Re: getting processor numbers

[Ulrich Drepper]

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 â

Attachment: signature.asc
Description: OpenPGP digital signature