> From: Rik van Riel [mailto:riel@xxxxxxxxxx] > Subject: Re: [PATCHv2 8/9] zswap: add to mm/ > > On 01/07/2013 03:24 PM, Seth Jennings wrote: > > zswap is a thin compression backend for frontswap. It receives > > pages from frontswap and attempts to store them in a compressed > > memory pool, resulting in an effective partial memory reclaim and > > dramatically reduced swap device I/O. > > > > Additional, in most cases, pages can be retrieved from this > > compressed store much more quickly than reading from tradition > > swap devices resulting in faster performance for many workloads. > > > > This patch adds the zswap driver to mm/ > > > > Signed-off-by: Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx> > > I like the approach of flushing pages into actual disk based > swap when compressed swap is full. I would like it if that > was advertised more prominently in the changelog :) > > The code looks mostly good, complaints are at the nitpick level. > > One worry is that the pool can grow to whatever maximum was > decided, and there is no way to shrink it when memory is > required for something else. > > Would it be an idea to add a shrinker for the zcache pool, > that can also shrink the zcache pool when required? > > Of course, that does lead to the question of how to balance > the pressure from that shrinker, with the new memory entering > zcache from the swap side. I have no clear answers here, just > something to think about... Hey Rik -- A shrinker needs to be able to free up whole pages. I think Seth is working on this with zsmalloc but it's quite a bit harder when pursuing high density and page crossing which are the benefits, but also part of the curse, of zsmalloc. I have some ideas on how to do pressure balancing and plan to propose a topic for LSF/MM to discuss various questions involving in-kernel compression, with this sub-topic included. Hopefully all the developers contributing various in-kernel compression solutions will be able to attend and participate and we can start converging on upstreaming (and/or promoting) some of them. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
