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

[Dan Magenheimer]

> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx]
> Subject: Re: [PATCHv2 8/9] zswap: add to mm/
> 
> On 01/29/2013 04:21 AM, Lord Glauber Costa of Sealand wrote:
> > On 01/28/2013 07:27 PM, Seth Jennings wrote:
> >> Yes, I prototyped a shrinker interface for zswap, but, as we both
> >> figured, it shrinks the zswap compressed pool too aggressively to the
> >> point of being useless.
> > Can't you advertise a smaller number of objects that you actively have?
> 
> Thanks for looking at the code!
> 
> An interesting idea.  I'm just not sure how you would manage the
> underlying policy of how aggressively does zswap allow itself to be
> shrunk?  The fact that zswap _only_ operates under memory pressure
> makes that policy difficult, because it is under continuous shrinking
> pressure, unlike other shrinkable caches in the kernel that spend most
> of their time operating in unconstrained or lightly/intermittently
> strained conditions.

Hi Seth --

Zswap (as well as zcache) doesn't "_only_ operate under memory
pressure".  It _grows_ only under memory pressure but can get
smaller via frontswap_loads and frontswap_invalidates
at other times.  I agree that writeback (from zswap to the
real swap disk, what zswap calls "flush") need only occur
when under memory pressure, but that's when a shrinker is called.

FYI, the way that zcache does this (for swap pages) is the
zcache shrinker drives the number of wholepages used to store
zpages down to match the number of wholepages used for anonymous
pages.  In zswap terms, that means you would call zswap_flush_entry
in a zswap shrinker thread continually until

 zswap_pool_pages <= global_page_state(NR_LRU_BASE + LRU_ACTIVE_ANON) +
                     global_page_state(NR_LRU_BASE + LRU_INACTIVE_ANON)

The zcache shrinker (currently) ignores nr_to_scan entirely;
the fact that the zcache shrinker is called is the signal for
zswap/zcache to start flush/writeback (moving compressed pages out to
swap disk).  This isn't a great match for the system shrinker
API but it seems to avoid the "aggressively to the point of
being useless" problem so is at least a step in the right direction.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/