Critical vulnerability: Many allocations need to be done when decompressing a page e.g. temporary buffers required by decompression algos, final decompressed page etc. If any of these allocations fail in decompression code path, we essentially lose that data and corresponding applications crash. Do something about it! Possible solutions include having pre-allocated buffers (a.k.a. emergency pools) to avoid allocations in page decompression path but this has problems on how to have such emergency pools refilled (some background threads?). At least for clean page-cache pages, we can afford to fail in decompress path since their up-to-date copies are always on disk NOTE: If any of allocations fail during page compression, we simply let go that page though usual reclaim path (as when ccaching is not present).
Avoid/Delay OOM-kills: When we reach OOM(out-of-memory) situations, we should try to free all of ccache first before going for process kills. Currently, we actually pre-pone OOM-kills in some cases since all the pages given to ccache are pinned. Only in cases where pages are requested soon after they are compressed, we really do post-pone OOM killer. Solution to this problem involves part of work required to have dynamic ccaching support (ability to evict compressed pages from ccache to filesystem/swap disk).
Add config options for ccache: Currently no config options exist. Major work here is to completely #ifdef away ccache code if it’s not selected – most difficult part will be to deal with intrusive changes made in find_get_page() and friends.
Its size begins as a single page and expands as page are compressed and added to it (until it reaches its limit as set by user) and shrinks as pages are taken out and decompressed. (This is not adaptive resizing scheme).
Pages are cyclically compressed using WKdm, WK4x4 and LZO. This cyclical selection of compression algorithms makes no sense in real use but this is done just to show that its possible to compress each page with a different algo.