From: Minchan Kim <minchan@kernel.org>
To: Kyeongdon Kim <kyeongdon.kim@lge.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
ngupta@vflare.org, sergey.senozhatsky.work@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc()
Date: Tue, 24 Nov 2015 17:15:18 +0900 [thread overview]
Message-ID: <20151124081518.GC32717@blaptop> (raw)
In-Reply-To: <56541B22.8040909@lge.com>
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
next prev parent reply other threads:[~2015-11-24 8:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 6:21 [PATCH v3] zram: try vmalloc() after kmalloc() Kyeongdon Kim
2015-11-23 6:35 ` Minchan Kim
2015-11-23 7:26 ` Sergey Senozhatsky
2015-11-23 22:52 ` Andrew Morton
2015-11-23 23:28 ` Minchan Kim
2015-11-23 23:40 ` Andrew Morton
2015-11-24 0:35 ` Minchan Kim
2015-11-24 1:06 ` Sergey Senozhatsky
2015-11-24 3:56 ` Minchan Kim
2015-11-24 8:09 ` Kyeongdon Kim
2015-11-24 8:15 ` Minchan Kim [this message]
2015-11-24 7:56 ` Kyeongdon Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151124081518.GC32717@blaptop \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=kyeongdon.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan.kim@gmail.com \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.