[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stack base and thread-specific data

From: Igor Khavkine
Subject: Re: Stack base and thread-specific data
Date: Sun, 12 Aug 2001 00:55:09 -0400
User-agent: Mutt/1.3.20i

On Wed, Aug 08, 2001 at 10:50:46PM -0400, Roland McGrath wrote:
> Even without kernel limitations, you'd use up most of the address space
> with thread stacks (even small ones), and not have much left for the
> presumably large amount of data you'd be operating on if you needed so many
> threads, before you hit those limits.  
> There are also other kernel-assisted approaches to simulate a spare
> register to dedicate to a per-thread value that are easy implement and
> don't have such limitations.  e.g., having %gs:0 fixed at a location the
> kernel writes with a per-thread value on context switch.  This approach
> might also perform better since if you aren't using an LDT then Mach
> doesn't do an x86 "task switch" at all for a context switch (and perhaps
> the single store is cheaper).

Actually looking at the linuxthreads code does not give the full story.
Turns out Mach maintains an LDT table per thread, so the same selector
can be used in every thread because it will be indexing into different
descriptor tables. So Mach itself will be a bottleneck for the maximum
number of threads and not the library.

I think the best way to go about this is to simply change the way
__hurd_threadvar_location() obtain the address of the thread's threadvars.
I think the simplest solution would be to setup a descritor such
that if  %gs is loaded with the right selector, %gs:0 would be the 
address of the bottom of the stack. Then the location of threadvars
elements can be calculated from there, and everyone is happy.
Except the glibc routines that use __hurd_threadvar_location_from_sp()
and those that refer to __hurd_threadvar_stack_{mask,offset}.

Infact it should be possible to perform the switch this new way
right away because it is not pthreads specific. I can provide a
patch that will touch parts of glibc and [hurd]/libthreads. Or
should I wait a bit?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]