I believe you are taking the right approach to the problem, which is not
to complain about that we need 2*RAM, but to try and figure out _why_ we
need 2*RAM.
As far as I can make out, any pages that at one time got swapped out,
will remain in swap. It is even there when there are no more references
to the page, but will be reclaimed lazily (i.e. when we need to swap
something new out).
I'm assuming the reason we need SWAP > RAM is because once swap is filled
only the subset of VM users that occupy this space are candidates for
further swapping. I'm assuming this probably has a significant impact on
long-running processes that have more chance of being pushed into swap
at some point.
The advantage of this is that when we need to remove a clean page that
is already in swap we can simply discard the copy in ram, paying only a
swap-in penalty. Dirty pages will have to be re-written, but we don't
need to find a place to put them, swap is already reserved. If we wanted
reclaim swap pages that were swapped into ram, we need to find a place
to swap to, swap the page out, and eventually swap it back in. Obviously
a lot more expensive.
However, we must have pushed the page into swap because it was not
'pageable'. i.e. it got dirtied, and there is no underlying file to
write it back to, shm, private mmap, or dirty heap. So there is infact a
high likelyhood that the page will not be clean when we have to swap it
out again.
Now if we would reclaim not just dead swap pages, but also pages that
have been swapped in but are dirtied, the 'additional cost' only
involves finding a place to swap to. The nice thing is that with fewer
used swap pages as a result of agressive reclaiming of swapped but in
the mean time swapped back in and dirtied pages it should become a lot
easier to find a free spot (until we are really overcommitted).
I don't know how feasable it is to tell from a given swap page, whether
there is a dirtied copy present in ram, but we could drop the swap
reference when the copy in ram is modified, turning the swap page into a
dead page and letting the regular reclamation pick it up.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/