[Top] [All Lists]

Re: RM7k cache_flush_sigtramp

To: Ralf Baechle <>
Subject: Re: RM7k cache_flush_sigtramp
From: Fuxin Zhang <>
Date: Fri, 01 Aug 2003 22:18:50 +0800
Cc: Dominic Sweetman <>, Adam Kiepul <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
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:

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.

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.


<Prev in Thread] Current Thread [Next in Thread>