Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Carsten Langgaard <carstenl@mips.com>
To: "Sedjai, Mohamed" <MSedjai@tee.toshiba.de>
Cc: Jon Burgess <Jon_Burgess@eur.3com.com>,
	Ralf Baechle <ralf@oss.sgi.com>,
	"Gleb O. Raiko" <raiko@niisi.msk.ru>,
	linux-mips@oss.sgi.com
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
Date: Fri, 12 Jul 2002 11:40:59 +0200	[thread overview]
Message-ID: <3D2EA42B.5270BF76@mips.com> (raw)
In-Reply-To: CEEE372345CE51438B0EC15F09ADE2710910F8@dus04a.tsb-eu.com

"Sedjai, Mohamed" wrote:

> Hello everybody,
>
> I've been following this thread with much attention and interest,
> and I would like to give my small contribution, even though my expertise
> is far lower than yours.
>
> Our TX49 (R4000 based) manual also states that "if the CACHE instruction
> is issued for the line in which this instruction exists the operation
> is not guaranted". As you can see from the arch/mips/mm/r4xx0.c file,
> TX49 routines always disable caches before operating.
>
> Recently, one of our customer, raised the question since he was comparing
> performance between TX49 and another comparable MIPS architecture.
> He noticed a huge difference in favor of the other vendor.
> For information it was a multimedia application. Investigations
> showed that the other vendor was running cache flushing operations cached.
> He tried to also run TX49 cached and, miracle, TX49 performed much better
> than the other chip. And the application could run for hours without
> crashing.
>
> I have contacted our designers, and the answer I got so far is that a problem can
> occur depending on the alignement of the CACHE instructions and on the set
> in which they are located (TX49 cache is 4 way set). This confirms Jon's
> investigation. Carsten, can you comment this, as a MIPS insider ? Which
> CPUs are concerned ?

I can only speak for our own products (4Kc serie, 5Kc serie and 20Kc).
They have no problem with running the cache routine from cached space.

"Index load/store Tag" cache operation instructions, however should be executed from
uncached space, but they are not used in linux.

>
> Further investigation are now ongoing to find a proper workaround and thus suggestions
> are highly apreciated.
>
> >From my side I have a very simple question:
>
> If you run instruction cache flushing cached, then the cache will be dirty
> when the routine returns. At least the line(s) containing the routine itself ?
> Or am I missing something ?
>
> Best Regards,
>
> Mohamed SEDJAI
> TOSHIBA Electronics Europe
>
> PS: Sorry Dominic for a possible misusage of the terminology. BTW I found your book
> wonderfully well written and consider it as a reference to anyone who wants
> to write a technical book.
>
> -----Original Message-----
> From: Jon Burgess [mailto:Jon_Burgess@eur.3com.com]
> Sent: Donnerstag, 11. Juli 2002 18:34
> To: Ralf Baechle
> Cc: Gleb O. Raiko; linux-mips@oss.sgi.com; carstenl@mips.com
> Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with
> gcc-2.96
>
> > Ralf wrote:
> >Have you tried to insert a large number of nops instead?
>
> My investigation suggests that a single extra nop is sufficient. I have also
> tried inserting extra nops before the cache routine to see if the relative
> alignment of the instructions with respect to the cacheline has an influence,
> but it has no effect. I am suspicious that if this occurs with the instruction
> following the loop then something odd might be occuring on every loop iteration
> as well. I might try adjusting the instructions in the loop to see if that has
> any effect.
>
> >  Or preferably,
> >how about replacing the __restore_flags() in your example with the
> >following piece of inline assembler:
> >
> >  __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory");
>
> I am happy that the current assembler code looks correct, but this change would
> make it simpler.
>
>      Jon

--
_    _ ____  ___   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

  parent reply	other threads:[~2002-07-12  9:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-12  9:08 mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Sedjai, Mohamed
2002-07-12  9:08 ` Sedjai, Mohamed
2002-07-12  9:26 ` Geert Uytterhoeven
2002-07-12  9:40 ` Carsten Langgaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-22  8:18 Sedjai, Mohamed
2002-07-22  8:18 ` Sedjai, Mohamed
2002-07-15  9:42 Jon Burgess
2002-07-12 15:24 Jon Burgess
2002-07-11 16:33 Jon Burgess
2002-07-11 12:11 Jon Burgess
2002-07-11 16:53 ` Jun Sun
2002-07-11  9:49 Jon Burgess
2002-07-11 12:13 ` Ralf Baechle
2002-07-12  9:18 ` Carsten Langgaard
2002-07-10 14:16 Jon Burgess
2002-07-11  0:15 ` Ralf Baechle
2002-07-11  8:48   ` Gleb O. Raiko
2002-07-11  9:18     ` Carsten Langgaard
2002-07-11 10:06       ` Gleb O. Raiko
2002-07-11 10:15         ` Carsten Langgaard
2002-07-11 10:36           ` Gleb O. Raiko
2002-07-11 10:46             ` Carsten Langgaard
2002-07-11 11:12         ` Ralf Baechle
2002-07-11 17:01           ` Maciej W. Rozycki
2002-07-11 23:02             ` Dominic Sweetman
2002-07-12  0:24               ` Ralf Baechle
2002-07-12 10:37               ` Gleb O. Raiko
2002-07-12 18:40               ` Maciej W. Rozycki
2002-07-11 11:23         ` Maciej W. Rozycki
2002-07-11 13:11           ` Gleb O. Raiko
2002-07-11 13:41             ` Maciej W. Rozycki
2002-07-11 15:27               ` Gleb O. Raiko
2002-07-11 15:59                 ` Maciej W. Rozycki
2002-07-12 10:26                   ` Gleb O. Raiko
2002-07-12 19:02                     ` Maciej W. Rozycki
2002-07-15  9:16                       ` Gleb O. Raiko
2002-07-16  9:00                         ` Maciej W. Rozycki
2002-07-16 10:20                           ` Gleb O. Raiko
2002-07-16 10:36                             ` Maciej W. Rozycki
2002-07-11  7:34 ` Carsten Langgaard

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=3D2EA42B.5270BF76@mips.com \
    --to=carstenl@mips.com \
    --cc=Jon_Burgess@eur.3com.com \
    --cc=MSedjai@tee.toshiba.de \
    --cc=linux-mips@oss.sgi.com \
    --cc=raiko@niisi.msk.ru \
    --cc=ralf@oss.sgi.com \
    /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