Re: getting processor numbers

[Ulrich Drepper <drepper@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Andi Kleen wrote:
> I would be opposed for adding another page per process at least
> because the per process memory footprint in Linux is imho already
> too large.

That's a single page shared by all threads on the system.  Or make this
a page per NUMA node.  And if the number of threads is larger than the
share counter for page, create a few more.

But in general the extra overhead would be minimal from the memory
consumption POV.


>> No, why?  The vdso call would be so inexpensive (just a simple function
>> call) that it can be done whenever a topology-based decision has to be
>> made.  Use cookies to determine whether nothing has been changed since
>> the last call etc.
> 
> But how would that mix with the OpenMP use case where you have
> thread pools that normally don't make decisions afer startup, but 
> just stay around?

There is a different between having threads in the thread pool and
actually using them.  For every #omp loop the number of processors is
checked again and this is the number of threads from the pool which is used.


> I think for those you would need events of some sort
> to start or remove threads as needed. 

We need no events if determining the number of processors is cheap.
There is really no reason why it shouldn't.  Restarting all the threads
is not the cheapest operation so a single syscall (sys_sysconf, etc)
does not increase the cost a lot.


> If there's a good use case fine for me. However I suspect it's
> either "slow is ok" or "want it very fast" where even a syscall
> would hurt.

Ideally, as I said, an optimized vdso call is best.  But a syscall is
OK.  The nice thing about the vdso is that for now one could simply
implement it using a syscall and in future add optimizations to avoid
the kernel entry if possible.

A single syscall is two order of magnitude better than the best solution
available today.  This is my main concern right now.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]