Hi,
On Mon, Oct 02, 2000 at 03:13:07AM +0200, Daniel Phillips wrote:
> What I've seen proposed is a mechanism where the VM can say 'flush this
> page' to a filesystem and the filesystem can then go ahead and do what
> it wants, including flushing the page, flushing some other page, or not
> doing anything and just being part of the problem. I'm having trouble
> seeing that as a clear way for the VM to communicate what it wants. Why
> is it interested in *that* page in particular?
Because the VM has access to the usage patterns of those pages, and is
in the best position to tell which pages are oldest and should be
sent to disk and cleared from memory most quickly.
> Passing in the target page seems to be an attempt at communicating some
> of the LRU information that the VM maintains. If so, this is a very
> low-bandwidth way of doing that. I have to admit I haven't studied the
> VM the way I should, I'm still trying to preserve the fiction that one
> can write a filesystem without getting involved in the memory manager.
> But here is a half-baked idea: how about exporting the page aging
> mechanism so a filesystem can age its own pages.
Because the filesystem doesn't have anything to do with page aging.
Page aging is something that happens in the VM to react to user
pressure in the page cache etc. It's not something which the
filesystem has any business caring about.
There's good reason for this. If you have multiple different types
of pages (eg. mmaped or not, mlocked or not, and pages from different
filesystems) in the cache, then how is any one filesystem _ever_ going
to be able to take a balanced look at memory and decide which pages
are ripe to be evicted? Only the VM has that global knowledge.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:12 EST