Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161657AbbKTAsJ (ORCPT ); Thu, 19 Nov 2015 19:48:09 -0500 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34333 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934361AbbKTAsG (ORCPT ); Thu, 19 Nov 2015 19:48:06 -0500 Date: Fri, 20 Nov 2015 09:49:04 +0900 From: Sergey Senozhatsky To: "kyeongdon.kim" Cc: Sergey Senozhatsky , minchan@kernel.org, Andrew Morton , linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com Subject: Re: [PATCH] zram: Prevent page allocation failure during zcomp_strm_alloc Message-ID: <20151120004904.GA4262@swordfish> References: <1447916068-28385-1-git-send-email-kyeongdon.kim@lge.com> <20151119094535.GA592@swordfish> <564DD354.1090006@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564DD354.1090006@lge.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2751 Lines: 79 Hello, On (11/19/15 22:49), kyeongdon.kim wrote: [..] > I know what you mean (streams are not free). > First of all, I'm sorry I would have to tell you why I try this patch. nothing to be sorry about. > When we're using LZ4 multi stream for zram swap, I found out this > allocation failure message in system running test, > That was not only once, but a few. Also, some failure cases were > continually occurring to try allocation order 3. > I believed that status makes time delay issue to process launch. ahhh, I see. repetitive allocation failures during heavy I/O and low memory conditions. hm... does it actually make any sense to make something like this (*just an idea*) --- diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c index 5cb13ca..049ae6b 100644 --- a/drivers/block/zram/zcomp.c +++ b/drivers/block/zram/zcomp.c @@ -124,6 +124,19 @@ static struct zcomp_strm *zcomp_strm_multi_find(struct zcomp *comp) zstrm = zcomp_strm_alloc(comp); if (!zstrm) { spin_lock(&zs->strm_lock); + /* + * If current IO path has failed to allocate a new + * stream then most likely lots of subsequent IO + * requests will do the same, wasting time attempting + * to reclaim pages, printing warning, etc. Reduce + * the number of max_stream and print an error. + */ + if (zs->max_strm > 1) { + zs->max_strm--; + pr_err("%s: reduce max_comp_streams to %d\n", + "Low memory", + zs->max_strm); + } zs->avail_strm--; spin_unlock(&zs->strm_lock); wait_event(zs->strm_wait, !list_empty(&zs->idle_strm)); --- A 'broken English' comment can shed some light on the idea. Hopefully, by the time we reduce ->max_strm there are N (>1) streams already. In the worst case we go down to a single stream, but that is something what would have happened anyway -- we don't have memory for N streams. We don't rollback the max_stream value (at least not in this version); we basically don't know when the low memory condition goes away -- may be never. > So I tried to modify this by pre-allocating and solved it, even if there > was small memory using in advance. > > But because of this patch, if there is an unneeded memory using. > I want to try new patch from another angle. > Firstly, we can change 'vmalloc()' instead of 'kzalloc()' for the > 'zstrm->private". Yes, we can try this, I guess. > Secondly, we can use GFP_NOWAIT flag to avoid this warning after 2nd > stream allocation. GFP_NOWAIT. hm... no, I don't think so. -ss -- 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/