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

[Daniel Jacobowitz]

On Thu, Feb 10, 2005 at 01:25:13PM -0800, Michael Uhler wrote:
> 
> > 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.
> 
> I wouldn't exactly say that it's OK with us.  The impression that I get is
> that it's too late to change, and even if it weren't we'd have to prove that
> the trap-and-emulate approach had performance problems.  We have to trade
> that off with our own desire to get NPTL supported, even if we have a
> feeling that the implementation may cause problems in the future.

Let me quote a message you didn't directly answer:

   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.


I'm not asking for "proof" that there are performance problems.  I'm
asking for something that I can understand as more than a "feeling",
since I "feel" that there aren't.  I'm trying to be responsive to your
concerns, but I'm still having trouble getting a handle on why
(whether?) you think any of the other ideas presented are better than
emulating rdhwr.

Please, if you have a better proposal...

> So, I have allocated RDHWR register 29 (decimal) for use as the pseudo-TLS
> pointer.  What this means is that we have changed the architecture documents
> to indicate that this register is used for an ABI-related activity such that
> it will never be re-allocated for another purpose.  At this point, we do not
> intend to implement this as a hardware register, nor will other MIPS
> implementations be doing so.  We'll revisit this (as an architecture change)
> once we measure the performance impact of the proposal and compare that with
> other potential changes to the ABI.

Thank you.  We'll need to choose a preferred GPR for the fast-path
emulation also; Thiemo suggested $3, which sounds reasonable to me.  The
choice does not make a great deal of difference.

> Based on the email thread, I'm not sure if Mark's suggestion of a compromise
> by marking the RDHWR with a relocation has benefit or not.  If it does, it
> would be nice to have some hedge in the future.

I don't think it adds any additional value.  It would only be useful if
we wanted to replace the one instruction with any single other
instruction in legacy code; most things will be rebuildable and I do
not see the application startup time overhead as preferable to the
kernel emulation for legacy code.  Does anyone else see a scenario in
which this would be good to have?

-- 
Daniel Jacobowitz
CodeSourcery, LLC