From: "Kevin D. Kissell" <KevinK@mips.com>
To: "Kevin D. Kissell" <KevinK@mips.com>,
"S C" <theansweriz42@hotmail.com>,
"Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: Re: Strange, strange occurence
Date: Tue, 13 Jul 2004 00:25:37 +0200 [thread overview]
Message-ID: <021201c4685f$2925ee30$0deca8c0@Ulysses> (raw)
In-Reply-To: 020201c46859$fa6b98b0$0deca8c0@Ulysses
> Your intuition is correct, and the code in r4k_tlb_init() does look scary.
> But at least in the linux-mips CVS tree, flush_icache_range() tests to see
> if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume)
> is set, and if it isn't, it pushes the specified range out of the Dcache before
> flushing the Icache. I would speculate that either your c-r4k.c is out of
> sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc
> set.
Hmm. On closer examination, there *is* a bug in the current r4k_flush_icache_range(),
in that it computes its cache flush loop for the I-cache based on the D-cache line size.
Those line sizes are *usually* the same. By any chance are they different for the
TX49 family? If the icache line is longer than the dcache line, there should be no
functional problem, just some wasted cycles. But if the dcache line were, say,
twice the length of the Icache line, only half of the icache lines would be invalidated...
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <KevinK@mips.com>
To: "Kevin D. Kissell" <KevinK@mips.com>,
S C <theansweriz42@hotmail.com>,
Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Strange, strange occurence
Date: Tue, 13 Jul 2004 00:25:37 +0200 [thread overview]
Message-ID: <021201c4685f$2925ee30$0deca8c0@Ulysses> (raw)
Message-ID: <20040712222537.bt21tE1Gj7v95TcNMkBGYc4JZ2BCukbF1fYlLlvbM_o@z> (raw)
In-Reply-To: 020201c46859$fa6b98b0$0deca8c0@Ulysses
> Your intuition is correct, and the code in r4k_tlb_init() does look scary.
> But at least in the linux-mips CVS tree, flush_icache_range() tests to see
> if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume)
> is set, and if it isn't, it pushes the specified range out of the Dcache before
> flushing the Icache. I would speculate that either your c-r4k.c is out of
> sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc
> set.
Hmm. On closer examination, there *is* a bug in the current r4k_flush_icache_range(),
in that it computes its cache flush loop for the I-cache based on the D-cache line size.
Those line sizes are *usually* the same. By any chance are they different for the
TX49 family? If the icache line is longer than the dcache line, there should be no
functional problem, just some wasted cycles. But if the dcache line were, say,
twice the length of the Icache line, only half of the icache lines would be invalidated...
Regards,
Kevin K.
next prev parent reply other threads:[~2004-07-12 22:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-12 21:23 Strange, strange occurence S C
2004-07-12 21:48 ` Kevin D. Kissell
2004-07-12 21:48 ` Kevin D. Kissell
2004-07-12 22:25 ` Kevin D. Kissell [this message]
2004-07-12 22:25 ` Kevin D. Kissell
2004-07-12 23:13 ` Ralf Baechle
2004-07-12 23:11 ` Ralf Baechle
2004-07-12 23:00 ` Ralf Baechle
-- strict thread matches above, loose matches on Subject: below --
2004-07-30 21:06 G H
2004-07-31 5:09 ` Ralf Baechle
2004-07-12 23:10 S C
2004-07-12 20:49 S C
2004-07-09 18:50 S C
2004-07-10 7:33 ` Niels Sterrenburg
2004-07-10 10:04 ` Ralf Baechle
2004-07-12 15:16 ` Kevin D. Kissell
2004-07-12 15:16 ` Kevin D. Kissell
2004-07-13 0:33 ` Ralf Baechle
2004-07-13 15:31 ` Kevin D. Kissell
2004-07-13 15:31 ` Kevin D. Kissell
2004-07-14 12:02 ` Maciej W. Rozycki
2004-07-14 16:35 ` Dominic Sweetman
2004-07-14 17:45 ` Michael Uhler
2004-07-14 17:45 ` Michael Uhler
2004-07-15 1:34 ` Atsushi Nemoto
2004-07-15 1:53 ` Ralf Baechle
2004-07-16 12:24 ` Ralf Baechle
2004-07-16 16:05 ` Atsushi Nemoto
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='021201c4685f$2925ee30$0deca8c0@Ulysses' \
--to=kevink@mips.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=theansweriz42@hotmail.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.