TLS register for NPTL

TLS register for NPTL

[Carl van Schaik]

Hi All,

It seems the rdhwr emulation is used/proposed for accessing the thread
word in NPTL.
I've been reading some of the posts from 2005 about this choice of this
and what I have missed is anyone talking about using the "k0" register
for TLS. It seems logical that the kernel could always restore k0 on
returning to user-land and having k1 only for the last part of returning
to user is sufficient. Any reason why this was not looked at?

regards,
Carl van Schaik

Re: TLS register for NPTL

[Thiemo Seufer]

Carl van Schaik wrote:
> Hi All,
> 
> It seems the rdhwr emulation is used/proposed for accessing the thread
> word in NPTL.
> I've been reading some of the posts from 2005 about this choice of this
> and what I have missed is anyone talking about using the "k0" register
> for TLS. It seems logical that the kernel could always restore k0 on
> returning to user-land and having k1 only for the last part of returning
> to user is sufficient. Any reason why this was not looked at?

The TLB handlers need k0/k1 as well and have no good place to save/restore
a register.


Thiemo

Re: TLS register for NPTL

[Ralf Baechle]

On Mon, Aug 20, 2007 at 09:06:27AM +0100, Thiemo Seufer wrote:

> > It seems the rdhwr emulation is used/proposed for accessing the thread
> > word in NPTL.
> > I've been reading some of the posts from 2005 about this choice of this
> > and what I have missed is anyone talking about using the "k0" register
> > for TLS. It seems logical that the kernel could always restore k0 on
> > returning to user-land and having k1 only for the last part of returning
> > to user is sufficient. Any reason why this was not looked at?
> 
> The TLB handlers need k0/k1 as well and have no good place to save/restore
> a register.

It can be done but would require several extra instructions in the most
performance sensitive parts of the OS.

Aside, latest MIPS processors support a hardware implementation of rdhwr $29,
so there is no more emulation overhead for this instruction at full binary
compatibility.

  Ralf

Re: TLS register for NPTL

[Carl van Schaik]

Ralf Baechle wrote:
> On Mon, Aug 20, 2007 at 09:06:27AM +0100, Thiemo Seufer wrote:
>
>   
>>> It seems the rdhwr emulation is used/proposed for accessing the thread
>>> word in NPTL.
>>> I've been reading some of the posts from 2005 about this choice of this
>>> and what I have missed is anyone talking about using the "k0" register
>>> for TLS. It seems logical that the kernel could always restore k0 on
>>> returning to user-land and having k1 only for the last part of returning
>>> to user is sufficient. Any reason why this was not looked at?
>>>       
>> The TLB handlers need k0/k1 as well and have no good place to save/restore
>> a register.
>>     
>
> It can be done but would require several extra instructions in the most
> performance sensitive parts of the OS.
>
> Aside, latest MIPS processors support a hardware implementation of rdhwr $29,
> so there is no more emulation overhead for this instruction at full binary
> compatibility.
>   
Ok, I agree that this is probably the best way to go. In the L4
microkernel we have for a long time used k0 (sony did this as well?),
but that was before any rdhwr existed, hence my questions. It should be
easy to change L4 to use rdhwr, or both for an intermediate period of
time which allows us to virtualize Linux mips applications with NPTL.

thanks,
Carl

Re: TLS register for NPTL

[Ralf Baechle]

On Tue, Aug 21, 2007 at 11:53:49AM +1000, Carl van Schaik wrote:

> > Aside, latest MIPS processors support a hardware implementation of rdhwr $29,
> > so there is no more emulation overhead for this instruction at full binary
> > compatibility.
> >   
> Ok, I agree that this is probably the best way to go. In the L4
> microkernel we have for a long time used k0 (sony did this as well?),

For the PS2, yes.  Then again the R5900 design is screwed to the point where
it can't reasonably be exploited without adding another AI variant - but that
only makes the use of k0 a slightly less bad idea.

  Ralf