Re: __commit_write() with the Page Cache

From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Thu May 11 2000 - 19:35:42 EST


Linus Torvalds wrote:
>
> On Thu, 11 May 2000, Jeff V. Merkey wrote:
> > >
> > > (3) should in theory work, you just need to fill in page->buffers for it,
> > > and right now that may or may not do what you want. See the 99-pre7 code
> > > to sync the dang thing for you - it may be more along what you want done.
> > > And right now there is no way to "plug" the write - once page->buffers has
> > > been filled in, the write-back can happen at any time.
> >
> > Who does the write back? It looks like it's the buffer cache. So Pre7
> > fixes this flushing problem?
>
> Well, pre-7 does it differently.
>
> Earlier, what happened was that when the MM layer noticed that a page had
> dirty buffers on it, it would just ask bdflush to start writing things
> out. This does not work if those per-page dirty buffers aren't on the
> bdflush LRU lists - which they don't actually have to be. I'm considering
> getting rid of the bdflush LRU lists, and just relying on the page LRU
> list instead - because the MM layer does need the latter, and the former
> is really just another form of the same thing.

This would be a good idea I think to eliminate these lists.

>
> What pre-7 does is that when it needs more memory and the page it would
> like to free has buffers attached to it, pre-7 will just cause those
> buffers to be asycnhronously written out. It still cannot free the page,
> but the next time around it likely _will_ be able to free it, so the
> memory pressure automatically keeps the dirty buffer writeout going.
>
> Whether this suits your needs or not is unclear. It makes more sense to
> me, the old bdflush approach was really just a question of being lazy
> ("Oh, duh, we have dirty stuff, let's just do this one-liner that will
> cause it to be flushed eventually"). And it's a lot more flexible, and
> potentially makes it possible to just remove a lot of the old "global
> buffer LRU" code.

I will try it and let you know......

>
> (The page LRU is not as exact as the per-buffer LRU was, but it has other
> advantages, the main one obviously being the natural integration with the
> VM back-pressure. And "exact LRU" is probably not called for anyway - the
> locality that the page cache offers might actually be advantageous).

I'd not considered the impacts on the VM (but should after the baraage
of emails relate to recent VM changes).

:-)

Jeff

>
> Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:19 EST