Re: Syncing the page cache, take 2

[Daniel Phillips <news-innominate.list.linux.mm@innominate.de>]

Rik van Riel wrote:
> 
> On Wed, 16 Aug 2000, Daniel Phillips wrote:
> > Rik van Riel wrote:
> > > On Tue, 15 Aug 2000, Stephen C. Tweedie wrote:
> > >
> > > > Correct.  We have plans to change this in 2.5, basically by
> > > > removing the VM's privileged knowledge about the buffer cache
> > > > and making the buffer operations (write-back, unmap etc.) into
> > > > special cases of generic address-space operations.  For 2.4,
> > > > it's really to late to do anything about this.
> > >
> > > please take a look at my VM patch at http://www.surriel.com/patches/
> > > (either the -test4 or the -test7-pre4 one).
> > >
> > > If you look closely at mm/vmscan.c::page_launder(), you'll see
> > > that we should be able to add the flush callback with only about
> > > 5 to 10 lines of changed code ...
> > >
> > > (and even more ... we just about *need* the flush callback when
> > > we're running in a multi-queue VM)
> >
> > OK, but what about the case where the filesystem knows it wants
> > the page cache to flush *right now*?  For example, when a
> > filesystem wants to be sure the page cache is synced through to
> > buffers just before marking a consistent state in the journal,
> > say.  How does it make that happen?
> 
> There are some ugly tricks, like pinning the buffer so that
> the buffer flushing code can't flush it out. Most of these
> have the potential for messing up VM and making the box run
> out of memory or even making the box hang...
> 
> If the new VM makes it into 2.4, however, it should be
> relatively easy to add the flush callback as a function
> in page_launder(). Otherwise we could add yet another
> thing to shrink_mmap() ... we could do it, but I guess
> at the cost of some code readability  *grin*

I used such tricks in 2.2.13, they were horrible and fragile.  I really
hope the need to use them disappears soon and that the new mechanism
winds up taking a nice simple form.  

But that wasn't what I was worried about right now.  I am worried about
having a way for a filesystem to *cause* the page cache to be flushed. 
There are good reasons why a filesystem would want to cause the page
cache flush event to happen (as opposed to being told by the VM when to
make it happen).

The analogous function I mentioned a few posts ago is write_inode_now,
which causes an element in the inode cache to be synced to the buffer
cache.  Every time you have a cache, you need a way to sync it to the
next level down, and you need to be able to force that sync
(selectively!) from a high level in the filesystem.  Otherwise, the
filesystem can't be sure when it has a consistent state.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/