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

[Thiemo Seufer]

Michael Uhler wrote:
> 
> > From this discussion I am still inclined to stay with rdhwr.  
> > 30-60 cycles is not very long.
> 
> The problem that I'm having with this email thread is that I no longer
> understand what problem is being solved.

The short term goal is still to add TLS to the existing ABIs without
breaking source compatibility.

> You're getting push-back from the
> MIPS folks, including me, about a solution that uses emulation of an
> instruction which is unlikely to be actually implemented in hardware any
> time soon, if ever.  It sounds like the ARM people are having the same
> heartburn for the same reason.

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.

> There appears to be no appreciable
> benchmarking that suggests that a trap-and-emulate approach will be fine, or
> not so fine in terms of performance of the solution.

I looked for good NPTL benchmarks and decent performance comparisions
in the meanwhile. I found none at all for emulated TLS vs. TLS register.
Numbers were cited by

- mail(s) from Ulrich Drepper to the Linux Kernel Mailing List, which
  compares against linuxthreads, and uses some rather unrealistic loads
  like 100000 threads. The NPTL source has some highly synthetic
  benchmarks which might have been used to get those numbers.

- Some mails on developer mailing lists which cite a 1-2% performance
  improvement over linuxthreads for larger java applications. For that
  case the difference between emulated and hardware TLS appears to be
  negligable.

> If the problem we're trying to solve is to get NPTL to work on MIPS, period
> the end, then we can stop the email thread now.  That certainly seems to be
> the path we're taking as of now.
> 
> If we're trying to find a solution to the problem such that MIPS isn't at a
> competitive disadvantage, perhaps we should start looking for such a
> solution, rather than rejecting suggestions because of the changes to the
> current software implementation.
> 
> So can you please crisply state what problem we're trying to solve here, and
> the bounds on an acceptable solution from your point of view.  I'm really
> confused.

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.


Thiemo