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 from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
