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

[Daniel Jacobowitz]

On Wed, Feb 09, 2005 at 12:41:49PM -0800, 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.  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.  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.
> 
> 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.

My point is for NPTL to work.  Specifically:

  - Tying it to a new ABI is unacceptable in the short term, and
    possibly in the longer term, because of community pushback against
    additional ABIs.

  - Using a wired TLB entry gives kernel developers the shakes, because
    it restricts the available TLB slots, which can have complex
    effects on the performance of existing applications.

That only leaves methods which enter the kernel.  Our choices are via a
load from an unmapped page, via a syscall, or via an RI exception. 
Only one of those models is compatible with acceleration via future
hardware.

Using rdhwr does not provide cripplingly slow - or even perceptibly
slow - performance, and I'm using a much more expensive emulation layer
than Maciej's.  If the MIPS folks can clearly justify their concerns
about this solution, and some relevant ideas to benchmark the problem,
then maybe we can make forward progress.

As was just pointed out to me, Maciej's numbers are on the same order
of magnitude as a load miss.  Note that the rdhwr is never needed more
than once per function with an optimizing compiler.  I think that at
the cost of a load miss, you're getting a bargain.

-- 
Daniel Jacobowitz
CodeSourcery, LLC