This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches(1/3)
- From: Dan Kegel <dank at kegel dot com>
- To: "Hu, Boris" <boris dot hu at intel dot com>
- Cc: Philip Blundell <pb at nexus dot co dot uk>, Jakub Jelinek <jakub at redhat dot com>, "Perez-Gonzalez, Inaky" <inaky dot perez-gonzalez at intel dot com>,Daniel Jacobowitz <drow at mvista dot com>, Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>,"Libc-Alpha (E-mail)" <libc-alpha at sources dot redhat dot com>, "NPTL list (E-mail)" <phil-list at redhat dot com>
- Date: Fri, 30 May 2003 08:46:11 -0700
- Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches(1/3)
- References: <37FBBA5F3A361C41AB7CE44558C3448E1A1844@pdsmsx403.ccr.corp.intel.com>
I wonder what the performance impact is of having a system call in
THREAD_SELF. If it turns out to be too great, it may be possible to
reduce the overhead by adding some more support to the kernel. What
I've been thinking of is a way for applications to supply a pointer to
the kernel (via a new system call), and have it store the
current thread
ID at that address during context switch. That way, retrieving the
thread descriptor would be just a regular memory access.
This reminds me of vsyscalls. Can someone in the know compare and
contrast the current proposal and vsyscalls?
Thanks!
- Dan
p.s. Here's a recent message from around the time they switched
the vsyscall page from something created specially by the kernel
to a tiny ELF image:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105123323202704&w=2
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045