On Wed, 2002-05-29 at 14:00, Maciej W. Rozycki wrote: > 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 > reads). This is true; I hadn't thought about the cases of userland touching hardware directly. Of course, I think these cases should be hunted down and eliminated (go framebuffer device!), but alas, if that ever really happens, it's not going to be soon. > > 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. We may theoretically need these capabilities, but, given that several of the ports already get this wrong and no loud screaming has been heard, I wonder about the real need. Assuming we do need these capabilities in the syscall (and, really, it's pretty easy to make them right), I'm actually more wondering about the need for the __flush_cache_all() in the first place. The gdb stubs can use the defined interface without a problem (and, indeed, more efficiently. What they're doing now is overkill). That leaves the syscalls, which, if implemented properly, should also use the normal interface. I'm still looking for a reason for the existence of __flush_cache_all(). > 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. Woefully insufficient. :) I'm going to have a stab at editing that file when I feel like I have a complete understanding. Don't hold your breath. :) -Justin
