On 25.8.2015 6:22, Sergey Senozhatsky wrote: >>>> i'd argue that neither zbud nor zsmalloc are responsible for reacting >>>> to memory pressure, they just store the pages. It's zswap that has to >>>> limit its size, which it does with max_percent_pool. >>> >>> Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests >>> from zswap when zswap hits the limit. Zswap could easily add a shrinker that >>> would relay this requests in response to memory pressure as well. However, >>> zsmalloc doesn't implement the reclaim, or LRU tracking. >> >> I wrote a patch for zsmalloc reclaim a while ago: >> >> https://lwn.net/Articles/611713/ >> >> however it didn't make it in, due to the lack of zsmalloc LRU, or any >> proven benefit to zsmalloc reclaim. >> >> It's not really possible to add LRU to zsmalloc, by the nature of its >> design, using the struct page fields directly; there's no extra field >> to use as a lru entry. > > Just for information, zsmalloc now registers shrinker callbacks > > https://lkml.org/lkml/2015/7/8/497 Yeah but that's just for compaction, not freeing. I think that ideally zswap should track the LRU on the level of pages it receives as input, and then just tell zswap/zbud to free them. Then zswap would use its compaction to make sure that the reclaim results in actual freeing of page frames. Zbud could re-pair the orphaned half-pages to the same effect. -- 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>