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: Paul Jackson <pj at sgi dot com>
- To: Andi Kleen <ak at suse dot de>
- 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: Sun, 18 Jun 2006 17:15:11 -0700
- Subject: Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- References: <200606140942.31150.ak@suse.de>
Interesting - thanks Andi.
I had one of my colleagues at SGI lobby me hard for such a facility.
I'll see if I can get him on this thread to better explain what he
wanted it for.
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.
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?
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
Windows command from the year 1999. I doubt that's it. You wrote:
> As you can see CPUID(1) is always very slow
but but I don't see any stats above the comment mentioning CPUID(1),
so ... er eh ... no I don't see.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401