This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patches (1/3)


On Thu, May 29, 2003 at 03:15:23PM +0100, Philip Blundell wrote:
> On Fri, 2003-05-23 at 09:23, Hu, Boris wrote:
> > However, TLS is absent in arm toolchain. So here is a work-around way. 
> > In the linux kernel, a thread register is simulated by an additional field(pd_addr) 
> > to thread_struct and two system calls(sys_get/set_thread_area()).  __thread 
> > keyword is disabled in glibc and nptl. Moreover, some code related TLS in nptl 
> > is protected by the glibc macro USE_TLS. 
> 
> Thanks for working on this.
> 
> 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.  I think it'd
> only add a handful of cycles to the context switch path, and that's a
> comparatively heavyweight operation already so it would probably
> disappear in the noise.

If ARMs are never going to be SMP, this seems like good idea
if there are no spare registers.
Then TLS support could be built on top of that in binutils/gcc/glibc
and NPTL support could be added.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]