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

[Daniel Jacobowitz]

On Wed, Feb 09, 2005 at 03:46:33PM -0800, 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.
> 
> 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.
> 
> 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.
> 
> To me, it all comes down to whether this is a final, unchangable, solution
> or not.

There's a couple of different possibilities covered by "final" and
"unchangeable".  The one thing I'm most desperate to avoid is something
that becomes impossible or extremely difficult to support later.  Once
we publish this as part of an ABI, there will soon be deployed systems
using it; I don't want to have to force them to transition to something
else.  The TP access instruction ends up in both system libraries and
user applications, so there's real legacy impact.

Rdhwr could end up in this state, if MIPS determines that there is not
an available register encoding or that devoting one to this usage is a
bad idea.  If that's the case, let us know - we'll have to go back to
the drawing board.

[FYI: ARM actually uses a function call for application TP access.  I
think this is a bad design decision, which is why I haven't proposed it
for MIPS.  Having to make a function call tacks even more overhead onto
IE/LE access, particularly userspace register pressure.]

However, if we're willing to support whatever we choose here for the
unspecified future, I don't see a big barrier to choosing a new,
superior approach later.  Probably none of the toolchain components
would be affected; they could seamlessly transition to a new model. The
kernel would have to continue to support the existing model and the new
model; I'll leave that answer to the kernel developers reading this,
but I believe that Maciej's patches would not be infeasible to
maintain.

If this is OK with you, I'd appreciate it if you could get back to us
about the choice of register number.  I've got at least a couple more
days worth of work before the port will be ready.  It won't cripple me
to sit on it for a couple weeks after that, but I'd love to have it
submitted - I've already started to get requests for the code.

-- 
Daniel Jacobowitz
CodeSourcery, LLC