linux-mips
[Top] [All Lists]

Re: [PATCH] fast path for rdhwr emulation for TLS

To: macro@linux-mips.org
Subject: Re: [PATCH] fast path for rdhwr emulation for TLS
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Sun, 09 Jul 2006 01:12:59 +0900 (JST)
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <Pine.LNX.4.64N.0607071715360.25285@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64N.0607071607520.25285@blysk.ds.pg.gda.pl> <20060708.011245.82794581.anemo@mba.ocn.ne.jp> <Pine.LNX.4.64N.0607071715360.25285@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Fri, 7 Jul 2006 17:58:44 +0100 (BST), "Maciej W. Rozycki" 
<macro@linux-mips.org> wrote:
> > Thanks, now I understand the problem.  Are there any good solutions?
> > Only I can think now is using handle_ri_slow for such CPUs.
> 
>  I have implemented an appropriate update to the TLB handlers (or actually 
> it's enough to care for this case for the TLBL exception), but it predates 
> the current synthesized ones.  There is a small impact resulting from 
> this change and the synthesized handlers have the advantage of making it 
> only necessary for these chips that do need such handling.

Do you still have the code?  Could you post it for reference?

>  I'd restructure the code more or less like this, taking care for (almost) 
> all stalls resulting from interlocks on coprocessor moves and memory loads 
> and likewise avoiding the need for "nop" fillers there for MIPS I 
> processors:

Thanks.  I'll look it deeply.

>       bne     k0, k1, handle_ri_slow  /* if not ours */
>        get_saved_sp                   /* k1 := current_thread_info */

Unfortunately, get_saved_sp is not a single instruction...

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>