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
next prev 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