Messages in this thread | | | Date | Tue, 24 Nov 2015 17:15:18 +0900 | From | Minchan Kim <> | Subject | Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc() |
| |
On Tue, Nov 24, 2015 at 05:09:06PM +0900, Kyeongdon Kim wrote: > On 2015-11-24 오전 8:28, Minchan Kim wrote: > > Hello Andrew, > > > > On Mon, Nov 23, 2015 at 02:52:26PM -0800, Andrew Morton wrote: > >> On Mon, 23 Nov 2015 15:21:15 +0900 Kyeongdon Kim > > <kyeongdon.kim@lge.com> wrote: > >> > >> > When we're using LZ4 multi compression streams for zram swap, > >> > we found out page allocation failure message in system running test. > >> > That was not only once, but a few(2 - 5 times per test). > >> > Also, some failure cases were continually occurring to try allocation > >> > order 3. > >> > > >> > In order to make parallel compression private data, we should call > >> > kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order > >> > 2/3 size memory to allocate in that time, page allocation fails. > >> > This patch makes to use vmalloc() as fallback of kmalloc(), this > >> > prevents page alloc failure warning. > >> > > >> > After using this, we never found warning message in running test, also > >> > It could reduce process startup latency about 60-120ms in each case. > >> > > >> > ... > >> > > >> > --- a/drivers/block/zram/zcomp_lz4.c > >> > +++ b/drivers/block/zram/zcomp_lz4.c > >> > @@ -10,17 +10,25 @@ > >> > #include <linux/kernel.h> > >> > #include <linux/slab.h> > >> > #include <linux/lz4.h> > >> > +#include <linux/vmalloc.h> > >> > +#include <linux/mm.h> > >> > > >> > #include "zcomp_lz4.h" > >> > > >> > static void *zcomp_lz4_create(void) > >> > { > >> > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL); > >> > + void *ret; > >> > + > >> > + ret = kzalloc(LZ4_MEM_COMPRESS, > >> > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC); > >> > + if (!ret) > >> > + ret = vzalloc(LZ4_MEM_COMPRESS); > >> > + return ret; > >> > } > >> > >> What's the reasoning behind the modification to the gfp flags? > >> > >> It clears __GFP_FS, __GFP_IO and even __GFP_WAIT. I suspect the latter > >> two (at least) can be retained. And given that vmalloc() uses > > > > This function is used in swapout and fs write path so we couldn't use > > those flags. > > > >> GFP_KERNEL, what's the point in clearing those flags for the kmalloc() > >> case? > > > > When I reviewed this patch, I wanted to fix it with another patch > > because we should handle another places in zcomp and Sergey sent it > > today. But I think Sergey's patch is stable material so I hope > > Kyeongdon resend this patch with fixing vmalloc part. > > > >> > >> If this change (or something like it) remains in place, it should have > >> a comment which fully explains the reasons, please. > > > > Kyeongdon, Could you resend this patch with fixing vzalloc part and > > adding comment? > > > Sorry for the delay in replying, > I just checked your comments and patch set. > > [PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate stream > [PATCH 2/3] zram: try vmalloc() after kmalloc() > [RFC 3/3] zram: pass gfp from zcomp frontend to backend > > First of all, thanks for your summary and organized code set, and > If Sergey agrees with that, I have no question about the patch 2/3.
Thanks. I will send revised version tomorrow.
> > >> > > > > -- > > Kind regards, > > Minchan Kim >
-- Kind regards, Minchan Kim
| |