>>>>> "stephen" == Stephen C Tweedie <sct@redhat.com> writes:
Hi
stephen> It doesn't matter. *If* the filesystem knows better than the
stephen> page cleaner what progress can be made, then let the filesystem
stephen> make progress where it can. There are likely to be transaction
stephen> dependencies which mean we have to clean some pages in a specific
stephen> order. As soon as the page cleaner starts exerting back pressure
stephen> on the filesystem, the filesystem needs to start clearing stuff,
stephen> and if that means we have to start cleaning things that shrink_
stephen> mmap didn't expect us to, then that's fine.
I don't like that, if you put some page in the LRU cache, that means
that you think that _this_ page is freeable. Yes some times that can
fail, but in the _normal_ case things just work that way. It doesn't
make sense to have pages in the LRU cache that are unfreeable and each
time that we ask the filesystem code to free them it tolds us:
- Well that page is actually busy, but I have that other free
instead.
If we really need a notify to the relevant fs that tells it: We are
short of memory, please free as much memory as possible. Where as
much as possible is an ammount related to the priority number (or any
other number).
I like the idea of having pages of Journaled FS in the cache if I can
ask the FS: free this page, and the fs will write/free that page and
*possible* more pages, but I am not *interested* in that detail.
If you need pages in the LRU cache only for getting notifications,
then change the system to send notifications each time that we are
short of memory.
Later, Juan.
-- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy- 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:29 EST