Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Guido Guenther" <agx@sigxcpu.org>, <linux-mips@linux-mips.org>,
	<debian-toolchain@lists.debian.org>
Subject: Re: TLS register
Date: Tue, 1 Jun 2004 14:44:08 +0200	[thread overview]
Message-ID: <047701c447d6$28aa9d60$10eca8c0@grendel> (raw)
In-Reply-To: 20040601121520.GB25718@linux-mips.org

> On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:
> 
> > Hi,
> > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > take this ABI change as a possibility to additionally reserve a TLS
> > register. 
> > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > which is already abused by the PS/2 folks for ll/sc emulation.
> > Another possibility would be to reserve such a register only in the
> > n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> 
> Sigh, we'e been through this really often enough.  Reserving a register
> comes at a price so my approach was to implement a fast path in the
> exception code.  I've benchmarked that long time ago; it had less than
> half the overhead than normal syscall and such a function would be subject
> to normal code optimizations so calls should be few only.  Alpha already
> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org, debian-toolchain@lists.debian.org
Subject: Re: TLS register
Date: Tue, 1 Jun 2004 14:44:08 +0200	[thread overview]
Message-ID: <047701c447d6$28aa9d60$10eca8c0@grendel> (raw)
Message-ID: <20040601124408.OMNgnzzKqqAGOcXuLzGNmVsPpldFdb8AgjZC4qJKGG8@z> (raw)
In-Reply-To: 20040601121520.GB25718@linux-mips.org

> On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:
> 
> > Hi,
> > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > take this ABI change as a possibility to additionally reserve a TLS
> > register. 
> > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > which is already abused by the PS/2 folks for ll/sc emulation.
> > Another possibility would be to reserve such a register only in the
> > n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> 
> Sigh, we'e been through this really often enough.  Reserving a register
> comes at a price so my approach was to implement a fast path in the
> exception code.  I've benchmarked that long time ago; it had less than
> half the overhead than normal syscall and such a function would be subject
> to normal code optimizations so calls should be few only.  Alpha already
> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

  reply	other threads:[~2004-06-01 12:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-31 23:05 TLS register Guido Guenther
2004-06-01  3:17 ` Steven J. Hill
2004-06-01 12:15 ` Ralf Baechle
2004-06-01 12:44   ` Kevin D. Kissell [this message]
2004-06-01 12:44     ` Kevin D. Kissell
2004-06-01 14:28     ` Maciej W. Rozycki
2004-06-01 19:21       ` David Daney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='047701c447d6$28aa9d60$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=agx@sigxcpu.org \
    --cc=debian-toolchain@lists.debian.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox