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, 3 Apr 2007 20:11:00 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: getting processor numbers

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/