Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753141AbbKWCPN (ORCPT ); Sun, 22 Nov 2015 21:15:13 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:40165 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753084AbbKWCPK (ORCPT ); Sun, 22 Nov 2015 21:15:10 -0500 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Mon, 23 Nov 2015 11:15:31 +0900 From: Minchan Kim To: Kyeongdon Kim Cc: ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc Message-ID: <20151123021531.GA10428@bbox> References: <1448013764-21899-1-git-send-email-kyeongdon.kim@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448013764-21899-1-git-send-email-kyeongdon.kim@lge.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5348 Lines: 158 Hello, On Fri, Nov 20, 2015 at 07:02:44PM +0900, Kyeongdon Kim 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 in that time, page allocation fails. > This patch makes to use vmalloc() as fallback of kmalloc(), this > prevents page alloc failure warning. > > After this, we never found warning message in running test, also > It could reduce process startup latency about 60-120ms in each case. Very nice! > > For reference a call trace : > > Binder_1: page allocation failure: order:3, mode:0x10c0d0 > CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20 > Call trace: > [] dump_backtrace+0x0/0x270 > [] show_stack+0x10/0x1c > [] dump_stack+0x1c/0x28 > [] warn_alloc_failed+0xfc/0x11c > [] __alloc_pages_nodemask+0x724/0x7f0 > [] __get_free_pages+0x14/0x5c > [] kmalloc_order_trace+0x38/0xd8 > [] zcomp_lz4_create+0x2c/0x38 > [] zcomp_strm_alloc+0x34/0x78 > [] zcomp_strm_multi_find+0x124/0x1ec > [] zcomp_strm_find+0xc/0x18 > [] zram_bvec_rw+0x2fc/0x780 > [] zram_make_request+0x25c/0x2d4 > [] generic_make_request+0x80/0xbc > [] submit_bio+0xa4/0x15c > [] __swap_writepage+0x218/0x230 > [] swap_writepage+0x3c/0x4c > [] shrink_page_list+0x51c/0x8d0 > [] shrink_inactive_list+0x3f8/0x60c > [] shrink_lruvec+0x33c/0x4cc > [] shrink_zone+0x3c/0x100 > [] try_to_free_pages+0x2b8/0x54c > [] __alloc_pages_nodemask+0x514/0x7f0 > [] __get_free_pages+0x14/0x5c > [] proc_info_read+0x50/0xe4 > [] vfs_read+0xa0/0x12c > [] SyS_read+0x44/0x74 > DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB > 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB > > Signed-off-by: Kyeongdon Kim If you fix kvfree Sergey pointed out, you can add my Acked-by: Minchan Kim > --- > drivers/block/zram/zcomp_lz4.c | 15 +++++++++++++-- > drivers/block/zram/zcomp_lzo.c | 15 +++++++++++++-- > 2 files changed, 26 insertions(+), 4 deletions(-) > > diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c > index f2afb7e..0477894 100644 > --- a/drivers/block/zram/zcomp_lz4.c > +++ b/drivers/block/zram/zcomp_lz4.c > @@ -10,17 +10,28 @@ > #include > #include > #include > +#include > +#include > > #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); One thing I feel bad smell is that call vzalloc with GFP_KERNEL. This function can be called in direct reclaim path with holding fs lock and GFP_KERNEL can enter recursive reclaim path so lockdep would complain theoretically if I don't miss something. If it is true, we should fix several allocation flags in zcomp_strm_alloc. I just want to record this warning for the future in this thread so someone who is finding for the contribution material will prove and fix it. :) > + return ret; > } > > static void zcomp_lz4_destroy(void *private) > { > - kfree(private); > + if (is_vmalloc_addr(private)) > + vfree(private); > + else > + kfree(private); > } > > static int zcomp_lz4_compress(const unsigned char *src, unsigned char *dst, > diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c > index da1bc47..613fbac 100644 > --- a/drivers/block/zram/zcomp_lzo.c > +++ b/drivers/block/zram/zcomp_lzo.c > @@ -10,17 +10,28 @@ > #include > #include > #include > +#include > +#include > > #include "zcomp_lzo.h" > > static void *lzo_create(void) > { > - return kzalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL); > + void *ret; > + > + ret = kzalloc(LZO1X_MEM_COMPRESS, > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC); > + if (!ret) > + ret = vzalloc(LZO1X_MEM_COMPRESS); > + return ret; > } > > static void lzo_destroy(void *private) > { > - kfree(private); > + if (is_vmalloc_addr(private)) > + vfree(private); > + else > + kfree(private); > } > > static int lzo_compress(const unsigned char *src, unsigned char *dst, > -- > 1.8.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/