From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Dominic Sweetman <dom@mips.com>, Jun Sun <jsun@mvista.com>,
linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Date: Mon, 23 Aug 2004 21:13:19 +0200 [thread overview]
Message-ID: <20040823191319.GA29165@linux-mips.org> (raw)
In-Reply-To: <20040823174446.GA8197@nevyn.them.org>
On Mon, Aug 23, 2004 at 01:44:47PM -0400, Daniel Jacobowitz wrote:
> Personally, I favor doing the low-overhead syscall for o32 and then
> moving to the new ABI that MIPS is talking about with a thread
> register.
I was always wondering how far gcc could optimize code to minimize this
special system call. After all on Alpha something similar PAL-code based
was the method of choice.
> I'm not sure what to do about n32/n64.
I believe N32 / N64 are not widespead enough yet to be a big roadblock
for moving to new ABIs. Whoever disagress should better speak up soon :-)
If we deciede to move to something entirely different than the existing
ABIs in the future will be able to support compatibility the same way
we're already doing.
> > Other crazy ideas did include a per-thread mapping containing the thread
> > pointer - and possibly more information in the future.
>
> Does MIPS have an efficient way to do this for SMP?
It can be done making the TLB fault for that page about as expensive as
a null syscall.
> > On the positive side if we had multiple register sets on a MIPSxx V2
> > processor we could exploit that to get rid of this overheade and do
> > other nice optimizations for TLB reload also. Unfortunately these
> > register sets are optional feature of the architecture only.
>
> That's more or less what was talked about for ARM v6.
I'm unARMed here ;-)
Ralf
next prev parent reply other threads:[~2004-08-23 19:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-04 22:29 anybody tried NPTL? Jun Sun
2004-08-05 1:08 ` Kumba
2004-08-05 17:14 ` Jun Sun
2004-08-06 2:03 ` Ralf Baechle
2004-08-19 14:17 ` Dominic Sweetman
2004-08-19 14:31 ` Alec Voropay
2004-08-19 14:31 ` Alec Voropay
2004-08-20 6:07 ` Dominic Sweetman
2004-08-20 6:07 ` Dominic Sweetman
2004-08-23 12:28 ` Ralf Baechle
2004-08-23 15:09 ` Alec Voropay
2004-08-23 15:09 ` Alec Voropay
2004-08-23 17:19 ` Ralf Baechle
2004-08-19 16:01 ` David Daney
2004-08-20 6:19 ` Dominic Sweetman
2004-08-19 22:16 ` Jun Sun
2004-08-20 13:46 ` Dominic Sweetman
2004-08-23 13:28 ` Daniel Jacobowitz
2004-08-23 17:12 ` Ralf Baechle
2004-08-23 17:44 ` Daniel Jacobowitz
2004-08-23 19:13 ` Ralf Baechle [this message]
2004-08-23 17:37 ` Jun Sun
2004-08-23 19:25 ` Ralf Baechle
2004-08-20 13:12 ` Thiemo Seufer
2004-08-20 16:52 ` Dominic Sweetman
2004-09-01 9:17 ` Richard Sandiford
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=20040823191319.GA29165@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=dan@debian.org \
--cc=dom@mips.com \
--cc=jsun@mvista.com \
--cc=linux-mips@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.