Thread (10 messages) 10 messages, 5 authors, 2003-08-04

Re: RM7k cache_flush_sigtramp

From: Fuxin Zhang <hidden>
Date: 2003-08-01 14:19:16

I just run a fresh new 2.4.21 kernel on my board, no luck.  The problem 
remains.
But I notice that my hardware may have some problems,especially with the 
add-on
ide card. Keep headaching...

As to the discussion of SYNC, I can't help wondering whether the cache 
management
should be totally hidden from programmers. People tends to write 
"safetest" code because
of all kinds of brain-damage different hardware, which leads to 
inefficient code. And this will
cancel out the potential speed benefit of simpler hardware. Also today's 
hardware seems not
as expensive as it was before...


Ralf Baechle wrote:
On Fri, Aug 01, 2003 at 08:51:39AM +0100, Dominic Sweetman wrote:

 
quoted
The MIPS32/MIPS64 release 2 architecture includes a useful instruction
SYNCI which does the whole job (repeat on each affected cache line)
and is legal in user mode; this will take a while to spread but I'd
recommend it as a model worth following.
   
 
quoted
So I hope that kernels will provide one function for "I've just
written instructions and now I want to execute them", and not export
the separate writeback-D/invalidate-I interface.
   
Linux supports the traditional MIPS UNIX cacheflush(2) syscall through
a libc interface.  Since I've not seen any other use for the call than
I/D-cache synchronization.  I'd just make cacheflush(3) use SYNCI where
available (Or maybe one of the other vendor specific mechanisms ...) and
fallback to cacheflush(2) where available.  Gcc would be another place
to teach about SYNCI for it's trampolines.

 Ralf



 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help