Re: getting processor numbers

[Andi Kleen <andi@firstfloor.org>]

On Tue, Apr 03, 2007 at 11:05:49AM -0700, Ulrich Drepper wrote:
> Andi Kleen wrote:
> >> There is an inexpensive solution: finally make the vdso concept a bit
> >> more flexible.  You could add a vdso call to get the processor count.
> >> The vdso code itself can use a data page mapped in from the kernel.
> > 
> > The ELF aux vector is exactly that already.
> 
> No.  The aux vector cannot be changed after the process is changed.  The
> memory belong to the process and not the kernel.  It must be possible at
> any time to get the correct information even if the system changed.

That's probably debatable, but ok.

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.
 
> >> This page (read-only at userlevel) would contain global information such
> >> as processor count and topology.
> > 
> > You would still need an event notification mechanism, won't you?
> 
> 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? I think for those you would need events of some sort
to start or remove threads as needed. 

Asking the kernel every time you submit some work to the threads
would probably not fly.
 
> > If you want it cheap look for some other way.
> 
> Well, who's brace enough to submit sys_sysconf() again?

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.

-Andi