RE: [PATCHv2 8/9] zswap: add to mm/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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

--
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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]