On 29 May 2002, Justin Carlson wrote:
> Are the general semantics of the thing just broken, then? We already
> ignore the arguments to sys_cacheflush; would redefining the syscall to
> mean "flush the caches in such a way that I won't get stale instructions
> from this address range" actually break any current programs?
> (Evidently not, if several ports are already doing it that way)...
You mean removing the DCACHE operation? The overlying _flush_cache()
library function is specified by the MIPS ABI supplement, so we shouldn't
really redefine it. Also a reasonable use for it may exist -- a userland
program touching hardware directly (say X11) may want to use cached
accesses for performance reasons (e.g. because cache can do prefetches on
I guess the intent for the ICACHE operation is to assure ICACHE vs DCACHE
coherency and the intent for the DCACHE operation is to assure DCACHE vs
RAM coherency. If the operations do not work in this way for a given
backend, then there is a bug in it.
> More to the point, does __flush_cache_all() serve any useful purpose at
> all, or can it just be replaced with appropriate invocations of
> flush_icache_range()? Other than internal use for the individual port
> cache routines, it's *only* used in the syscalls and the gdb stub.
It does serve a useful purpose. Or at least it should. This reminds me
of adding flushing of WB caches at a system shutdown. The function should
remain at least for this purpose.
If there are places you are absolutely sure flush_icache_range() would
suffice, feel free to replace the call. There are not many
> I'd like to hear the rationale for __flush_cache_all() from the original
> author; it appears to have shown up in CVS a little more than a year
> ago, but I don't know who sent the patch to Ralf. Ralf, do you
I converted a few flush_cache_all() invocations to __flush_cache_all()
where appropriate late last year, but the function is a bit older. I
think you might dig the linux-kernel list archives for a discussion on the
semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and
friends. The short description in Documentation/cachetlb.txt is a bit
insufficient, I'm afraid.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +