> I have something which should work. I think Rik has been hiding the
> problem and I just noticed that I accepted into 99 a patch that definitely
> should _not_ go in (the thing to change the "state" variable whether a
> free operation works or not is wrong - we want to keep freeing from one
> pool as long as it is "easy".
This only happens when both buffermem and pagecache are
below their borrow limits, but your change is probably
right anyway. The change back to the roundrobin freeing
of pages was only introduced because of people complaining
of ping-pong behaviour wrt. the buffer and page cache size.
> Rik, if you have problems with this under certain circumstances (like
> swapping out too much even though there is plenty of buffers left), that
> indicates that something is being too aggressive even though "i" (the
> "aggressivemess factor") is set to a high value ("i = 6" means that it
> shouldn't try all that hard, while "i = 0" means that we're really close
> to meltdown and we should go crazy).
I'll do some tests and update the documentation accordingly.
The dcache shrinking thing you did (moving it inside the
page freeing routine) will however decrease system performance
since discarding dcache data 'causes' otherwise unneccesary
disk seeks. [NOTE: I haven't read the patch yet, much less
tried it]
Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page | Scouting webmaster |
| - kswapd ask-him & complain-to guy | Vries cubscout leader |
| http://www.phys.uu.nl/~riel/ | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu