Rik van Riel wrote:
>
> On Sun, 1 Oct 2000, bert hubert wrote:
> >
> > If Rik gets some kind of memory pressure callback API in the
> > kernel, there is no theoretical reasons why the journalling
> > filesystems couldn't be merged safely.
>
> Once the VM is stable with the current feature set and OOM
> handling has been added, I'll probably look at the support
> code for the journaling filesystems.
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? What should we read into
its interest in a particular page? That the page looks stale? If that
page can't be written just now, this mechanism provides no help in
finding a suitable substitute.
Instead of calling the filesystem repeatedly, how about just telling it
the bad news: the amount of cache the VM thinks the filesystem should be
using for a particular superblock, and perhaps the amount the VM thinks
the filesystem is using now. This wouldn't need to be a function call
at all. The only reason you need a function call is to wake up the
filesystem so it can take action.
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.
These are half-formed ideas, I just want to make it clear that the
one-page-at-a-time memory pressure callback seems a little unsatisfying.
-- Daniel - 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:08 EST