From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753648AbbKYMsR (ORCPT ); Wed, 25 Nov 2015 07:48:17 -0500 Received: from mail-pa0-f54.google.com ([209.85.220.54]:36032 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbbKYMsQ (ORCPT ); Wed, 25 Nov 2015 07:48:16 -0500 Date: Wed, 25 Nov 2015 21:46:47 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Andrew Morton , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Kyeongdon Kim Subject: Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend Message-ID: <20151125124647.GA525@swordfish> References: <1448430673-10766-1-git-send-email-minchan@kernel.org> <1448430673-10766-3-git-send-email-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448430673-10766-3-git-send-email-minchan@kernel.org> 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 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. So we don't have to add comments to lz4/lzo backend that are getting (re-)moved in the very next commit. I will send swapped 2 and 3 patches shortly (I didn't change commit messages and SoBs). Please take a look. > - /* > - * 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 > - /* > - * 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(LZO1X_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > - __GFP_NOWARN|__GFP_NOMEMALLOC); > + > + ret = kmalloc(LZO1X_MEM_COMPRESS, flags); > if (!ret) > - ret = __vmalloc(LZO1X_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > - __GFP_NOWARN|__GFP_NOMEMALLOC| > - __GFP_ZERO, > - PAGE_KERNEL); > + ret = __vmalloc(LZO1X_MEM_COMPRESS, flags, PAGE_KERNEL); ditto. -ss