This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- From: Andi Kleen <ak at suse dot de>
- To: Paul Jackson <pj at sgi dot com>
- Cc: discuss at x86-64 dot org, linux-kernel at vger dot kernel dot org, libc-alpha at sourceware dot org, vojtech at suse dot cz
- Date: Mon, 19 Jun 2006 10:21:03 +0200
- Subject: Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- References: <200606140942.31150.ak@suse.de> <20060618171511.e0e6de26.pj@sgi.com>
On Monday 19 June 2006 02:15, Paul Jackson wrote:
>
> Roughly, he was looking to support something resembling the kernel's
> per-cpu data in userland library code for high performance scientific
> number crunching, for things like statistics gathering and perhaps (not
> sure of this) reduce locking costs.
While vgetcpu() can be used for this most likely glibc TLS is already
good enough for this. So it will help, but I don't think it's the primary
motivation.
> I see "x86-64" in the Subject. I don't see why this facility is
> arch-specific. Could it work on any arch, ia64 being the one of
> interest to me?
The implementation is x86-64 specific and optimized for x86-64. You could
probably implement something with the same prototype for IA64 too,
although the internal implementation will likely be very different
(there is nothing x86-64 specific in the prototype)
AFAIK ia64 supports fast system calls so it might be possible to
do a simple implementation without vsyscalls.
> I have some ignorance on your references to "CPUID(1)". I don't recall
> what it is. The only command so named I find on my systems are a
CPUID 1 is a x86 instruction that is one way to implement a user level
vgetcpu on x86.
-Andi