linux-mips
[Top] [All Lists]

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

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH] fast path for rdhwr emulation for TLS
From: Nigel Stephens <nigel@mips.com>
Date: Sun, 10 Sep 2006 23:30:18 +0100
Cc: ralf@linux-mips.org, dan@debian.org, macro@linux-mips.org, linux-mips@linux-mips.org
In-reply-to: <20060909.225641.41198763.anemo@mba.ocn.ne.jp>
Organization: MIPS Technologies Inc
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060711025342.GA6898@nevyn.them.org> <20060711.122014.52129937.nemoto@toshiba-tops.co.jp> <4501AABC.1050009@mips.com> <20060909.225641.41198763.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.5 (Windows/20060719)
Atsushi Nemoto wrote:
On Fri, 08 Sep 2006 18:39:08 +0100, Nigel Stephens <nigel@mips.com> wrote:
I asked on GCC bugzilla a few days ago but can not got feedback yet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
In spite of the GCC issue, is this patch now at the point where it could
be applied, or at least queued?

GCC 4.2 does not put RDHWR in delay slot now.  Also, there is a
"hackish fix" to prevent gcc move a RDHWR outside of a conditional
(from Richard Sandiford).

For kernel side, my patch can be still applied to current git tree as
is.

But I'm still looking for better solution (silver bullet?) for
cpu_has_vtag_icache case.

How about something like this (and do not touch tlbex.c)?

        LEAF(handle_ri_rdhwr_vivt)
        .set    push
        .set    noat
        .set    noreorder
        /* check if TLB contains a entry for EPC */
        MFC0    K1, CP0_ENTRYHI
        andi    k1, ASID_MASK
        MFC0    k0, CP0_EPC
        andi    k0, PAGE_MASK << 1
        or      k1, k0
        MTC0    k1, CP0_ENTRYHI
        tlbp
        mfc0    k1, CP0_INDEX
        bltz    k1, handle_ri   /* slow path */
         nop
        /* fall thru */
        LEAF(handle_ri_rdhwr)

I'm wondering if this could work on CONFIG_MIPS_MT_SMTC case...


No, that wouldn't be reliable for CONFIG_MIPS_MT_SMTC, but then again the only CPU which currently runs SMTC has VIPT caches

Nigel

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