From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FF56C433E0 for ; Thu, 25 Jun 2020 13:34:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4A98C20781 for ; Thu, 25 Jun 2020 13:34:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A98C20781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C8FA38D0003; Thu, 25 Jun 2020 09:34:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C413E8D0002; Thu, 25 Jun 2020 09:34:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2F8F8D0003; Thu, 25 Jun 2020 09:34:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 99A968D0002 for ; Thu, 25 Jun 2020 09:34:25 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3A9DE824556B for ; Thu, 25 Jun 2020 13:34:25 +0000 (UTC) X-FDA: 76967828490.07.linen82_1e02d2426e4d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 094D61803F9A4 for ; Thu, 25 Jun 2020 13:34:25 +0000 (UTC) X-HE-Tag: linen82_1e02d2426e4d X-Filterd-Recvd-Size: 5562 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Thu, 25 Jun 2020 13:34:24 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id o11so5854099wrv.9 for ; Thu, 25 Jun 2020 06:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gso1n2O6qGt4XCAgbt0r3fAr2sgINjgku+sh5gi1NWY=; b=pWkMWqduOVvGUfnY2+aHMWJ2Ta4xZwt3/9f2gDbLt1Bgyzhg3b5WB+sOYNBOFNlG7s MV9s4kWVX1901cSDIm7H2BJ3bPMuhhK4Clar38dF5RmaUC89XWBdzNJPZm2dp6+hTbyS jjrLrfgBFdUqVVbTgKFLjt7H8Bc9lDgANwGgwsaO0UaruKFsRU11S8SunKDyZsXmZpk4 N+iZ3MRzrs9/1tberSdicJNEB0GAqjtKMKLzGjWfBJkslwKX51RnWQgM7Dkis2ycnDE2 +cTcjFjkySFU8pDSNRHQ6bygLdWAIH5GGJeVv6xSKnZsKZI6340/wPyk8uXqwxRs2ogT T74A== X-Gm-Message-State: AOAM5314tatAAypkZSMqCGNDH+WNi0n1WvleiuZhZZCjrTUYUtqRH06D WV2b5J6e0lGP43WvI243e30= X-Google-Smtp-Source: ABdhPJzpVrNaN5j5rVGXAiejljpXNjMiCVf/+8PXhmVJ4820v+TwTrdbGmEOyJwMQNORqxQ5JfER4g== X-Received: by 2002:adf:9c8c:: with SMTP id d12mr6351189wre.369.1593092063507; Thu, 25 Jun 2020 06:34:23 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id v66sm12924082wme.13.2020.06.25.06.34.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 06:34:22 -0700 (PDT) Date: Thu, 25 Jun 2020 15:34:20 +0200 From: Michal Hocko To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, dm-devel@redhat.com, Mikulas Patocka , Jens Axboe , NeilBrown Subject: Re: [PATCH 6/6] mm: Add memalloc_nowait Message-ID: <20200625133420.GN1320@dhcp22.suse.cz> References: <20200625113122.7540-1-willy@infradead.org> <20200625113122.7540-7-willy@infradead.org> <20200625124017.GL1320@dhcp22.suse.cz> <20200625131055.GC7703@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200625131055.GC7703@casper.infradead.org> X-Rspamd-Queue-Id: 094D61803F9A4 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 25-06-20 14:10:55, Matthew Wilcox wrote: > On Thu, Jun 25, 2020 at 02:40:17PM +0200, Michal Hocko wrote: > > On Thu 25-06-20 12:31:22, Matthew Wilcox wrote: > > > Similar to memalloc_noio() and memalloc_nofs(), memalloc_nowait() > > > guarantees we will not sleep to reclaim memory. Use it to simplify > > > dm-bufio's allocations. > > > > memalloc_nowait is a good idea! I suspect the primary usecase would be > > vmalloc. > > That's funny. My use case is allocating page tables in an RCU protected > page fault handler. Jens' use case is allocating page cache. This one > is a vmalloc consumer (which is also indirectly page table allocation). > > > > @@ -877,7 +857,9 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client > > > */ > > > while (1) { > > > if (dm_bufio_cache_size_latch != 1) { > > > - b = alloc_buffer(c, GFP_NOWAIT | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN); > > > + unsigned nowait_flag = memalloc_nowait_save(); > > > + b = alloc_buffer(c, GFP_KERNEL | __GFP_NOMEMALLOC | __GFP_NOWARN); > > > + memalloc_nowait_restore(nowait_flag); > > > > This looks confusing though. I am not familiar with alloc_buffer and > > there is quite some tweaking around __GFP_NORETRY in alloc_buffer_data > > which I do not follow but GFP_KERNEL just struck my eyes. So why cannot > > we have > > alloc_buffer(GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN); > > Actually, I wanted to ask about the proliferation of __GFP_NOMEMALLOC > in the block layer. Am I right in thinking it really has no effect > unless GFP_ATOMIC is set? It does have an effect as an __GFP_MEMALLOC resp PF_MEMALLOC inhibitor. > It seems like a magic flag that some driver > developers are sprinkling around randomly, so we probably need to clarify > the documentation on it. Would the following make more sense? diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 67a0774e080b..014aa7a6d36a 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -116,8 +116,9 @@ struct vm_area_struct; * Usage of a pre-allocated pool (e.g. mempool) should be always considered * before using this flag. * - * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves. - * This takes precedence over the %__GFP_MEMALLOC flag if both are set. + * %__GFP_NOMEMALLOC is used to inhibit __GFP_MEMALLOC resp. process scope + * variant of it PF_MEMALLOC. So use this flag if the caller of the allocation + * context might contain one or the other. */ #define __GFP_ATOMIC ((__force gfp_t)___GFP_ATOMIC) #define __GFP_HIGH ((__force gfp_t)___GFP_HIGH) > What I was trying to do was just use the memalloc_nofoo API to control > what was going on and then the driver can just use GFP_KERNEL. I should > probably have completed that thought before sending the patches out. Yes the effect will be the same but it just really hit my eyes as this was in the same diff. IMHO GFP_NOWAIT would be easier to grasp but nothing I would dare to insist on. -- Michal Hocko SUSE Labs