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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.