> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
