On Mon, Feb 14, 2000 at 11:45:06PM +0000, Dominic Sweetman wrote:
> QED's RM7000 has an internal secondary cache which is more like (but
> not compatible with) an R4000. As part of our Linux familiarisation
> we'll try to get that working. It's 4-way set associative, 256Kbytes
> big, unified and write-back; so that should shake out some more bugs.
[...]
> I used to be an advocate of the MIPS position; but what this argument
> ignores is the difficulty of maintaining a portable software base,
> particulary an OS which (like Linux) has grown up with invisible x86
> caches.
>
> To make sure that Linux/MIPS kernels are and remain robust we have to
> convince lots of people to take the trouble to learn about visible
> caches - even though the systems they're working on don't have them.
> And we have to hope that driver writers will do the right thing, even
> though they've never used a system which needs cache management code
> and have none at hand to test their drivers with...
>
> This would be unlikely even if we all agreed what the word 'flush'
> meant (does it mean "invalidate"? or "write-back"? or perhaps "both,
> if necessary"? and can you build a robust OS without knowing the
> answer?)
Yes.
> It *could* happen. MIPS are not the only family of CPUs with visible
> caches - though I think they probably have by far the most complicated
> ones, because of their high-end history.
Sparc.
> The meeting of Linux and MIPS is in this respect really good for Linux
> - great at finding portability problems. But it's not particularly
> good for MIPS. For now, Linux/MIPS kernels will only be reliable if
> maintained by people who understand this stuff, keep a safe distance
> from the x86 mainstream, and use only sanity-checked drivers.
No longer. With Linux 2.3.41 Linux received a number of new software
interfaces which also could easily be backported to previous kernels.
As the side effect you even get scatter gather capabilities for every
driver.
Btw, please take a look at the new interfaces, they're documented in
Documentation/DMA-mapping.txt. They're not yet cast into stone, so if
anybody has something to complain about these interfaces, better do it
soon.
> Kevin, I think you'd better tell your colleagues who design the chips
> that they'd better put some snooping in, and soon...
For I/O isn't not that bad to handle except a few cases like the
NCR 53c8xx driver. And there is always the silver bullet solution of
using uncached accesses.
Things like mmap() and read/write right in the presence of virtual indexed
caches are the real vomit bag. Linus & Co. so far refuse to accept any of
the optimal solutions. And while I'd of course would like to such a
solution to get into the kernel I can well understand Linus' refusal.
>From that point of view the RM7000 is the first MIPS CPU that got caches
right since the R6000 ...
Ralf
|