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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:16 EST