KS2012: memcg/mm: Moving zcache towards the mainline

Posted Sep 19, 2012 23:03 UTC (Wed) by djm1021 (guest, #31130)
In reply to: KS2012: memcg/mm: Moving zcache towards the mainline by brendan_wright
Parent article: KS2012: memcg/mm: Moving zcache towards the mainline

This is exactly the direction that zcache2 (now under the staging/ramster) is moving. The hard part is that (1) two (or more) pageframes must be available to decompress the compressed pages, at a point in time where pageframes are alerady scarce, (2) moving those decompressed pages to the swap disk must be properly synchronized with swapping non-zcache pages to disk as there are some interesting race possibilities. A preliminary patch is already working, but poorly and will need more review and input from mm experts.

KS2012: memcg/mm: Moving zcache towards the mainline

Posted Sep 20, 2012 10:35 UTC (Thu) by Jonno (subscriber, #49613) [Link] (1 responses)

Why are pages decompressed as part of moving the page to disk, rather than as part of swapping in it to memory again? I can see no benefit of not storing the already compressed page on disk, deferring the decompression to when the content is actually needed (if ever).

KS2012: memcg/mm: Moving zcache towards the mainline

Posted Sep 20, 2012 16:09 UTC (Thu) by djm1021 (guest, #31130) [Link]

What you suggest is certainly possible (but anything is possible in software :-), however it would take fairly massive changes to the swap subsystem and/or userland-visible changes. Currently, the swap cache is an in-RAM mapping of some subset of pages on the swap disk and this is important for maintaining coherency between the (one or more user or kernel) threads accessing those pages and the I/O reading/writing the swap disk. If some pageframe-size slots on the swapdisk contain one or more compressed pages, this becomes a lot more complex.

In the end, such changes might be necessary or be the best alternative, but we are trying less invasive approaches first.