On 01/03/2013 08:30 PM, Dave Chinner wrote: >>> And so the two subsystems need different reclaim implementations. >>> > > And, well, that's exactly what we have shrinkers for - implmenting >>> > > subsystem specific reclaim policy. The shrinker infrastructure is >>> > > responsible for them keeping balance between all the caches that >>> > > have shrinkers and the size of the page cache... >> > >> > Given the above, do you think either compressed-anonymous-pages or >> > compressed-pagecache-pages are suitable candidates for the shrinker >> > infrastructure? > I don't know all the details of what you are trying to do, but you > seem to be describing a two-level heirarchy - a pool of compressed > data and a pool of uncompressed data, and under memory pressure are > migrating data from the uncompressed pool to the compressed pool. On > access, you are migrating back the other way. Hence it seems to me > that you could implement the process of migration from the > uncompressed pool to the compressed pool as a shrinker so that it > only happens as a result of memory pressure.... In our case, the mechanism for moving pages from the uncompressed pool (anonymous memory) to the compressed pool is the swapping mechanism itself. The mechanism for moving pages the other way is the page fault handler. To summarize my ideas wrt to zswap and the shrinker interface, I don't think there is a good use case here because all of the compressed pages in zswap are conceptually dirty. The writeback for these pages is both slow (bio write) and requires memory allocation. So zswap isn't a cache in the usual sense, where cache contents are clean, exist in RAM only for performance reasons, and can be freed in a lightweight way at any time. Thanks, Seth -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>