Re: journaling & VM (was: Re: reiserfs being part of the kernel: it'snot just the code)

From: Stephen C. Tweedie (sct@redhat.com)
Date: Wed Jun 07 2000 - 08:41:02 EST


Hi,

On Wed, Jun 07, 2000 at 10:23:35AM -0300, Rik van Riel wrote:
> >
> > There is no need for subcaches at all if all of the pages can be
> > represented on the page cache LRU lists. That would certainly
> > make balancing between caches easier.
>
> Wouldn't this mean we could end up with an LRU cache full of
> unfreeable pages?

Rik, we need the VM to track dirty pages anyway, precisely so that
we can obtain some degree of write throttling to avoid having the
whole of memory full of dirty pages.

If we get short of memory, we really need to start flushing dirty
pages to disk independently of the task of finding free pages.
Interrupts cannot wait for IO to complete --- they need the free
memory immediately. Page cleaning needs to be identified as a
very different job from page reclaiming. Whatever list we use to
track dirty pages can equally well be used for callbacks to
transactional filesystems.

> This could get particularly nasty when we have a VM with
> active / inactive / scavenge lists... (like what I'm working
> on now)

Right, we definitely need a better distinction between different
lists and different types of page activity before we can do this.

> Question is, are the filesystems ready to play this game?

With an address_space callback, yes --- ext3 can certainly find
a transaction covering a given page. I'd imagine reiserfs can do
something similar, but even if not, it's not important if the
filesystem can't do its lookup by page. The mere fact that the
filesystem sees the VM trying to scavenge dirty pages can trigger
it into starting to flush its oldest transactions, and that is
something that all filesystems should be able to do easily.

Cheers,
 Stephen

-
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 : Wed Jun 07 2000 - 21:00:28 EST