This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [discuss] Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- From: Andi Kleen <ak at suse dot de>
- To: Zoltan Menyhart <Zoltan dot Menyhart at bull dot net>
- Cc: discuss at x86-64 dot org, Chase Venters <chase dot venters at clientec dot com>, Brent Casavant <bcasavan at sgi dot com>, Jes Sorensen <jes at sgi dot com>, Tony Luck <tony dot luck at intel dot com>, linux-kernel at vger dot kernel dot org, libc-alpha at sourceware dot org, vojtech at suse dot cz, linux-ia64 at vger dot kernel dot org
- Date: Mon, 19 Jun 2006 10:54:29 +0200
- Subject: Re: [discuss] Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- References: <200606140942.31150.ak@suse.de> <200606170855.49123.ak@suse.de> <44966383.1030006@bull.net>
> Probably I have not explained it correctly:
> - The "information page" (that includes the current CPU no.) is not a
> per CPU page
If it isn't then you can't figure out the current CPU/node for a thread.
Anyways I think we're talking past each other. Your approach might
even work on ia64 (at least if you're willing to add a lot of cost
to the context switch). You presumably could implement vgetcpu()
internally with an approach like this (although with IA64's fast
EPC calls it seems a bit pointless)
It just won't work on x86.
-Andi