Messages in this thread |  | | Date | Sun, 17 Sep 2000 22:05:07 +0200 | From | Andrea Arcangeli <> | Subject | Re: Very aggressive swapping after 2 hours rest |
| |
On Sun, Sep 17, 2000 at 04:36:34PM -0300, Rik van Riel wrote: > On Sun, 17 Sep 2000, Andrea Arcangeli wrote: > > On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote: > > > The new VM, as integrated in -test9-pre1, does the same thing, > > > > Thanks for giving me some credit for my ideas. > > Your ideas? This is as much your idea as it is mine (which > it isn't). This is ancient stuff other OSes have been doing > for years ...
I don't know the internals of other OSes so I've no idea if that was a generic problem or not (guess why I started playing with linux: just to finally see the internals of an OS :) thus I don't know if this problem is generic or not.
Just to make sure if we're talking about the same thing, do you remeber when I told about the bigger problem under swap in 2.4.x? I remeber I explained this to you, SCT and Alexey.
The problem I'm talking about is the way we free the last reference to the swap cache after a swapout completes. It deals with subtle issues of the linux swap cache management (we didn't had this problem in 2.0.x) and it looks a very linux issue: an implementation bug.
The problem is/was that when in 2.1.x swap_out stopped to use the free_after logic to do the last free of the pages (when we started using shrink_mmap for freeing the last reference in the swap cache) we introduced a big problem in the memory balancing. This problem was one of the things addressed by classzone and as I told you this was the first problem to address for 2.4.x before anything else.
We have this problem in 2.2.x and this problem is been aggravated when I introduced a real LRU into 2.3.1x. With the real LRU the less interesting page in the system (the one we choosed to swapout because it have the accessed bit clear) become the one at the top of the LRU (not anymore in a random position as in 2.2.x) so to effectively swap 1 page out we had to throw away all the working set of clean cache. At least in 2.2.x when we inserted a page in the swap cache to free it, we at least had a chance not to be exactly at the other end of our round trip around the physical memory (making a comparison with 2.4.x in mean such page would be put the middle of the LRU, not at the top).
When I was explaining this to you you didn't even agreed with that and you was saying me that the swap cache shouldn't be shrink immediatly as soon as the swap _out_ I/O is completed (even while that was the major problem in the VM by that time).
If you fixed it I'm very happy and I thank you.
If you didn't fixed it (I'm not sure anymore since you seems to talk about things relative to other OSes as well) then ac22-class++ could still run faster than the new VM.
Andrea - 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/
|  |