From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754244AbbKYNuY (ORCPT ); Wed, 25 Nov 2015 08:50:24 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:52434 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752883AbbKYNuU (ORCPT ); Wed, 25 Nov 2015 08:50:20 -0500 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Wed, 25 Nov 2015 22:50:20 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: Andrew Morton , linux-kernel@vger.kernel.org, Kyeongdon Kim Subject: Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend Message-ID: <20151125135020.GA12747@bbox> References: <1448430673-10766-1-git-send-email-minchan@kernel.org> <1448430673-10766-3-git-send-email-minchan@kernel.org> <20151125124647.GA525@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151125124647.GA525@swordfish> 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 Hi Sergey, On Wed, Nov 25, 2015 at 09:46:47PM +0900, Sergey Senozhatsky wrote: > On (11/25/15 14:51), Minchan Kim wrote: > [..] > > + /* > > + * This function could be called in swapout/fs write path > > + * so we couldn't use GFP_FS|IO. And it assumes we already > > + * have at least one stream in zram initialization so we > > + * don't do best effort to allocate more stream in here. > > + * A default stream will work well without further multiple > > + * stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC. > > + */ > > + zstrm = zcomp_strm_alloc(comp, GFP_NOIO|__GFP_NORETRY| > > + __GFP_NOWARN|__GFP_NOMEMALLOC); > [..] > > I think that applying 3/3 before 2/3 will be a simpler (and probably a better) > thing to do. We fitst extend zcomp interface and pass flags (without any > functional change) and then extend the flags and introduce vmalloc fallback. The reason I ordered such way is that I wanted to discuss [2/3] as stable material after I get your ACK. It solves real problem in android platform which is real fact and I think it's enough small to send stable tree. What do you think? > > So we don't have to add comments to lz4/lzo backend that are getting (re-)moved > in the very next commit. Fair enough if you don't agree sending [2/3] to stable. > > I will send swapped 2 and 3 patches shortly (I didn't change commit > messages and SoBs). Please take a look. Thanks! > > > - /* > > - * This function could be called in swapout/fs write path > > - * so we couldn't use GFP_FS|IO. And it assumes we already > > - * have at least one stream in zram initialization so we > > - * don't do best effort to allocate more stream in here. > > - * A default stream will work well without further multiple > > - * stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC. > > - */ > > - ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > > - __GFP_NOWARN|__GFP_NOMEMALLOC); > > + ret = kmalloc(LZ4_MEM_COMPRESS, flags); > > if (!ret) > > - ret = __vmalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > > - __GFP_NOWARN|__GFP_NOMEMALLOC| > > - __GFP_ZERO, > > - PAGE_KERNEL); > > + ret = __vmalloc(LZ4_MEM_COMPRESS, flags, PAGE_KERNEL); > [..] > > __vmalloc() is still missing __GFP_HIGHMEM Argh, Sorry.