[mips-tls] A couple of potential changes to the MIPS TLS ABI

[Thiemo Seufer]

Michael Uhler wrote:
> 
> > Yes, and nobody backs up this concern with hard data. 
> > Maciej's numbers are good to know, but they tell nothing 
> > about how heavily the TLS implementation will be used in 
> > real-world applications.
> 
> > The assumption of "competitive disadvantage" is AFAICS 
> > unproven, and the schemes suggested to improve TLS 
> > performance may well turn out as over-engineering. Using e.g. 
> > a wired TLB is known to have a performance impact for all 
> > applications, the same is (probably to a lesser extent) true 
> > for reserving a GPR.
> 
> Both points are valid.  But they assume that if we DO have a performance
> problem, we'll be able to go back and fix that problem with an alternative
> method (something other than a new ABI).  It was my impression that we were
> discussing something that was not going to be easy to change once defined.

>From a technical POV it's not that hard to change the method. But
for adoption of NPTL it would be a disaster to create incompatible
variants after the initial deployment.

> So if we are proposing something that uses trap-and-emulate of rdhwr (whose
> register number will still have to change - I'll figure out what that is) as
> an initial proposal, and we're prepared to change it to address any
> performance problem that we find, I'm OK with that.

The current state is already well beyond the proposal phase. A potential
change of the current implementation would need to happen soon, and
would also need a sound reasoning. (Mark's idea of attaching a marker
relocation to the instruction is probably the best to keep an emergency
exit open. It would trade startup time for a TLS access change.)

> If we're not prepared to change things if we find a performance problem, I
> wonder why the burden of proof is on us to prove that we're not at a
> competitive disadvantage (something the ARM folks are obviously concerned
> about also) vs. the burden of proof being on having sufficient performance
> analysis to know that it will be fine.

The burden of proof is always on the side who wants to change a
working solution. :-)


Thiemo