[PATCHv7 4/8] zswap: add to mm/

[Dan Magenheimer]

> From: Seth Jennings [mailto:sjenning at linux.vnet.ibm.com]
> To: Dave Hansen
> Subject: Re: [PATCHv7 4/8] zswap: add to mm/
> 
> On 03/07/2013 01:00 PM, Dave Hansen wrote:
> > On 03/06/2013 07:52 AM, Seth Jennings wrote:
> > ...
> >> +**********************************/
> >> +/* attempts to compress and store an single page */
> >> +static int zswap_frontswap_store(unsigned type, pgoff_t offset,
> >> +				struct page *page)
> >> +{
> > ...
> >> +	/* store */
> >> +	handle = zs_malloc(tree->pool, dlen,
> >> +		__GFP_NORETRY | __GFP_HIGHMEM | __GFP_NOMEMALLOC |
> >> +			__GFP_NOWARN);
> >> +	if (!handle) {
> >> +		zswap_reject_zsmalloc_fail++;
> >> +		ret = -ENOMEM;
> >> +		goto putcpu;
> >> +	}
> >> +
> >
> > I think there needs to at least be some strong comments in here about
> > why you're doing this kind of allocation.  From some IRC discussion, it
> > seems like you found some pathological case where zswap wasn't helping
> > make reclaim progress and ended up draining the reserve pools and you
> > did this to avoid draining the reserve pools.
> 
> I'm currently doing some tests with fewer zsmalloc class sizes and
> removing __GFP_NOMEMALLOC to see the effect.

Zswap/zcache/frontswap are greedy, at times almost violently so.
Using emergency reserves seems like a sure way to OOM depending
on the workload (and luck).

I did some class size experiments too without seeing much advantage.
But without a range of "representative" data streams, it's very
hard to claim any experiment is successful.

I've got some ideas on combining the best of zsmalloc and zbud
but they are still a little raw.

> > I think the lack of progress doing reclaim is really the root cause you
> > should be going after here instead of just working around the symptom.

Dave, agreed.  See http://marc.info/?l=linux-mm&m=136147977602561&w=2 
and the PAGEFRAME EVACUATION subsection of
http://marc.info/?l=linux-mm&m=136200745931284&w=2