[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4612977D.4060903@redhat.com>
Date: Tue, 03 Apr 2007 11:05:49 -0700
From: Ulrich Drepper <drepper@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
CC: Linux Kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: getting processor numbers
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.
>> 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.
> The cost will be still large. Accessing sysfs will be never cheap.
> For once anything going through the VFS tens to take a two sometimes
> three digit number of locks.
That stat solution actually ain't that bad. It takes ~7400 cycles on my
machine.
> If you want it cheap look for some other way.
Well, who's brace enough to submit sys_sysconf() again?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)
Powered by blists - more mailing lists