Re: [linuxsh-dev] Re: [linux-sh:02750] Re: [PATCH] Ensure flush_page_to_ram does

[Stuart M. <stu...@st...>]

On Tue, 20 May 2003 14:59:22 +0100 ker...@be... wrote:

> On Tue, 2003-05-20 at 14:40, Stuart Menefy wrote:
> > Alex
> > 
> > Abe-san found a similar problem when using my TLB miss handling patches.
> > When using PIO there is no cache synchronisation in the generic IDE code,
> > while NFS has an explicit call to flush_dcache_page.
> 
> Well thats good. I guess there are two ways to crack this nut. I forgot
> to mention I'm also using your enhanced TLB miss patches - i take it the
> impication is that the old TLB handler didn't see these problems?

I don't remember seeing any, either personally or reported to the list.
However I've not run without my patches for some time now, and we don't
use IDE much. If its any help, SCSI disks appears to be rock solid.

> Are there any other issues with the TLB handler which are still keeping
> it out of the mainline (LinuxSH) tree?

Not really. I was hoping to get some wider testing, but I think there has
been as much as I can reasonably expect given that it involves applying
patches. So maybe I should just bite the bullet, check it in, and wait for
the screams!

Peter Garrone did a port to 2.5.13 a while ago, this should probably also
be brought up to date (if necessary) and applied to the 2.5 branch.

> > The solution we tried which has worked so far is based on the Sparc code,
> > which redefines the IO functions to include a cache synchronisation call.
> > The patch is attached. 
> 
> I guess by concentrating on just the IDE part this patch is more
> efficent as the cache is only flushed for the IDE operations rather than
> every time a file is mapped in. Is this scheduled to go into the LinuxSH
> tree?

Thats right. Plus the IDE use of insl/outsl is very predictable (its only
ever used for sector sized chunks into the buffer cache). I wouldn't
want to change the normal I/O functions as the overhead would be too high,
and would be unexpected in other circumstances.

I'll check this in at the same time as the cache related changes.

Stuart