Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Carsten Langgaard <carstenl@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Ralf Baechle <ralf@uni-koblenz.de>,
	linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards
Date: Tue, 30 Jul 2002 08:59:17 +0200	[thread overview]
Message-ID: <3D46393D.37D36612@mips.com> (raw)
In-Reply-To: 3D45A13E.79C882B5@mips.com

Carsten Langgaard wrote:

> "Maciej W. Rozycki" wrote:
>
> > Hello,
> >
> >  The except_vec1_r4k() function in arch/mips64/mm/tlbex-r4k.S is quite new
> > and seems specifically written to handle the EntryLo vs "tlbwr" R4k CP0
> > hazard by adding an extra "nop" before the "tlbwr" beyond what
> > except_vec1_r10k() puts.  Unfortunately, it does not work on my R4400SC
> > anyway.  OTOH, the 32-bit MIPS version does, so I tried bits from that for
> > MIPS64 and now the function works.
> >
> >  Here is the resulting patch.  Since barring the hazard fragment the
> > functions are identical, I removed the redundant part and made
> > except_vec1_r4k() make use of the LOAD_PTE2 and PTE_RELOAD macros.
> >
> >  OK to apply?
>
> I'm the one who added the except_vec1_r4k function, it works fine on my 5Kc, 20Kc and RM5261.
> I can't tell if your patch works for me, before trying it on one of the above CPUs, will do that tomorrow.
>

Your patch seems to work fine for me.
But now that we are looking at the TLB exception handler code, I have a few comments.
If the 2 exception handler functions are identical, maybe we could stick with just one function and make the hazard barrier depending on the
CPU configuration.
We have been discussing this before, but I really don't like the idea of solving the hazard problem with a branch. The branch will on some CPUs (especially if
they have a long pipeline) be a much bigger penalty than we actually wants to solve the hazard. On other CPU (with branch prediction) we may not even solve
the hazard problem.
The 'nop' I used is not the solution either, instead we should use 'ssnop' instructions, which will make sure we also solve the hazard problem on superscalar
CPUs.
We also need to have a hazard barrier in the code labeled "not_vmalloc".
What do you thing ?


>
> >
> >   Maciej
> >
> > --
> > +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> > +--------------------------------------------------------------+
> > +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> >
> > patch-mips-2.4.19-rc1-20020726-mips64-tlbex-r4k-1
> > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/tlbex-r4k.S
> > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/tlbex-r4k.S     2002-07-25 02:57:02.000000000 +0000
> > +++ linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/tlbex-r4k.S   2002-07-28 22:27:08.000000000 +0000
> > @@ -5,6 +5,7 @@
> >   *
> >   * Copyright (C) 2000 Silicon Graphics, Inc.
> >   * Written by Ulf Carlsson (ulfc@engr.sgi.com)
> > + * Copyright (C) 2002  Maciej W. Rozycki
> >   */
> >  #include <linux/config.h>
> >  #include <linux/init.h>
> > @@ -23,7 +24,7 @@
> >          * that caused the fault in in PTR.
> >          */
> >
> > -       .macro  LOAD_PTE2, ptr, tmp
> > +       .macro  LOAD_PTE2, ptr, tmp, kaddr
> >  #ifdef CONFIG_SMP
> >         dmfc0   \ptr, CP0_CONTEXT
> >         dmfc0   \tmp, CP0_BADVADDR
> > @@ -32,8 +33,8 @@
> >         dmfc0   \tmp, CP0_BADVADDR
> >         dla     \ptr, pgd_current
> >  #endif
> > -       bltz    \tmp, kaddr
> > -       ld      \ptr, (\ptr)
> > +       bltz    \tmp, \kaddr
> > +        ld     \ptr, (\ptr)
> >         dsrl    \tmp, (PGDIR_SHIFT-3)           # get pgd offset in bytes
> >         andi    \tmp, ((PTRS_PER_PGD - 1)<<3)
> >         daddu   \ptr, \tmp                      # add in pgd offset
> > @@ -75,34 +76,16 @@ FEXPORT(except_vec0)
> >         .align  5
> >  LEAF(except_vec1_r4k)
> >         .set    noat
> > -       dla     k1, pgd_current
> > -       dmfc0   k0, CP0_BADVADDR
> > -       ld      k1, (k1)
> > -       bltz    k0, vmaddr
> > -        dsrl   k0, (PGDIR_SHIFT-3)             # get pgd offset in bytes
> > -       andi    k0, ((PTRS_PER_PGD - 1)<<3)
> > -       daddu   k1, k0                          # add in pgd offset
> > -       dmfc0   k0, CP0_BADVADDR
> > -       ld      k1, (k1)                        # get pmd pointer
> > -       dsrl    k0, (PMD_SHIFT-3)               # get pmd offset in bytes
> > -       andi    k0, ((PTRS_PER_PMD - 1)<<3)
> > -       daddu   k1, k0                          # add in pmd offset
> > -       dmfc0   k0, CP0_XCONTEXT
> > -       andi    k0, 0xff0                       # get pte offset
> > -       ld      k1, (k1)                        # get pte pointer
> > -       daddu   k1, k0
> > -       ld      k0, 0(k1)                       # get even pte
> > -       ld      k1, 8(k1)                       # get odd pte
> > -       dsrl    k0, 6                           # convert to entrylo0
> > -       dmtc0   k0, CP0_ENTRYLO0                # load it
> > -       dsrl    k1, 6                           # convert to entrylo1
> > -       dmtc0   k1, CP0_ENTRYLO1                # load it
> > -       nop                                     # Need 2 cycles between mtc0
> > -       nop                                     #  and tlbwr (CP0 hazard).
> > +       LOAD_PTE2 k1 k0 9f
> > +       ld      k0, 0(k1)                       # get even pte
> > +       ld      k1, 8(k1)                       # get odd pte
> > +       PTE_RELOAD k0 k1
> > +       b       1f
> >         tlbwr
> > +1:
> >         nop
> >         eret
> > -vmaddr:
> > +9:
> >         dla     k0, handle_vmalloc_address
> >         jr      k0
> >          nop
> > @@ -116,14 +99,14 @@ END(except_vec1_r4k)
> >         .align  5
> >  LEAF(except_vec1_r10k)
> >         .set    noat
> > -       LOAD_PTE2 k1 k0
> > +       LOAD_PTE2 k1 k0 9f
> >         ld      k0, 0(k1)                       # get even pte
> >         ld      k1, 8(k1)                       # get odd pte
> >         PTE_RELOAD k0 k1
> >         nop
> >         tlbwr
> >         eret
> > -kaddr:
> > +9:
> >         dla     k0, handle_vmalloc_address      # MAPPED kernel needs this
> >         jr      k0
> >          nop

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

  reply	other threads:[~2002-07-30  6:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-29 15:23 [patch] MIPS64 R4k TLB refill CP0 hazards Maciej W. Rozycki
2002-07-29 20:10 ` Carsten Langgaard
2002-07-30  6:59   ` Carsten Langgaard [this message]
2002-07-30 11:29     ` Ralf Baechle
2002-07-30 12:09       ` Carsten Langgaard
2002-07-30 12:44         ` Maciej W. Rozycki
2002-07-30 22:47           ` Ralf Baechle
2002-07-31 11:34             ` Maciej W. Rozycki
2002-07-31 20:31               ` Ralf Baechle
2002-08-01 15:24                 ` Maciej W. Rozycki
2002-08-01 17:18                   ` Ralf Baechle
2002-08-02  9:32                     ` Carsten Langgaard
2002-08-02 11:05                       ` Ralf Baechle
2002-08-02 11:09                         ` Carsten Langgaard
2002-07-30 12:39       ` Kevin D. Kissell
2002-07-30 12:39         ` Kevin D. Kissell
2002-07-31  2:05         ` Ralf Baechle
2002-07-31  7:28           ` Kevin D. Kissell
2002-07-31  7:28             ` Kevin D. Kissell
2002-07-31 11:49             ` Maciej W. Rozycki
2002-07-31 18:22               ` Ralf Baechle

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=3D46393D.37D36612@mips.com \
    --to=carstenl@mips.com \
    --cc=linux-mips@fnet.fr \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@uni-koblenz.de \
    /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