And we intend to do exactly that with allocate on flush. Eventually we will
even repack on flush.
>
> This could get particularly nasty when we have a VM with
> active / inactive / scavenge lists... (like what I'm working
> on now)
>
> Then again, if the filesystem knows which pages we want to
> push, it could base the order in which it is going to flush
> its blocks on that memory pressure. Then your scheme will
> undoubtedly be the more robust one.
>
> Question is, are the filesystems ready to play this game?
Yes, we are eager to play, but you do intend that the filesystem will be
pressured to age not flush, yes?
That is, if aging causes something to get flushed, it gets flushed, but if not
then not.
The filesystems should get passed some notion of how much of their cache to age
so that you MM guys can have fun varying this.
You might want us to return how much got scheduled for flushing as a result of
the aging, that way you know when to stop pressuring caches.
>
> regards,
>
> Rik
> --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
> http://www.conectiva.com/ http://www.surriel.com/
-
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/