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

[Ralf Baechle]

On Wed, Feb 09, 2005 at 01:11:50PM +0000, Nigel Stephens wrote:

> One reason why MIPS is concerned about using rdhwr is that it may
> condemn the whole MIPS architecture to poor multi-threading
> performance relative to other architectures for some number of
> years. If the architecture gains a poor reputation in this area, then
> the mud could stick.

I'm not too concerned here because currently there seems to be very little
code available that exploits TLS.  As time progresses more such code
will be written and that I hope would be sufficient time for the hardware
folks, if we deciede to take that route.

> But I don't yet understand how important the thread pointer access
> time is for a typical threaded program. Can we get a better idea of
> the dynamic frequency of thread register loads? Does anyone know some
> suitable application programs or benchmarks which exercise the TLS
> mechanism, and from which we could extract some statistics?

That's a not very quantitative statement but the Alpha people are
apparently very satisfied with their PAL code exception based solution.
At least so said rth when I last spoke to him.

> To maintain single-threaded performance we'd perhaps want to increment
> the Wired count only when running real TLS code, so as not to reduce
> the number of TLB entries available for random replacement for the
> majority single-threaded applications.
> 
> I've spoken to Ralf about this idea, and though he's not thrilled by
> it, he hasn't (yet) said that it couldn't work.

My general feeling it's the kind of tradeoff that are sort of the
equivalent to juggling with razor blades with closed eyes ;-)  Or
translated into plain English, it's one of those optimizations which I
think have a strong potencial to fire back and actually result in a loss.
It's hard to say without actual application and without knowing the
size of the workload in advance.

> For multi-threaded CPUs the ultimate solution is the new ABI which
> reserves a GPR for the thread register. But in the short-term, before
> that new ABI is fully supported, a rdhwr-based implementation could be
> argued for.

A new ABI is alot of work, will take time and not last convincing.  We
want something sooner than that could happen.

> How do people feel about supporting two different TLS implementations
> on top of the existing MIPS ABIs - one optimised for legacy MIPS CPUs,
> and another for multi-threaded CPUs - similar to what ARM Linux seems
> to be considering for SMP?

It's a bit like hardware and software floating point, ll/sc and non-ll/sc
binaries which are flavours which we already have.  Once can only hope
that the number of binary variants won't reach the actual worst case
number.

  Ralf