> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
