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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77435C433F5 for ; Mon, 22 Nov 2021 16:54:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE6B26B006C; Mon, 22 Nov 2021 11:54:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D95F86B0072; Mon, 22 Nov 2021 11:54:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5E016B0073; Mon, 22 Nov 2021 11:54:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id B83F96B006C for ; Mon, 22 Nov 2021 11:54:40 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 80EC08248D7C for ; Mon, 22 Nov 2021 16:54:30 +0000 (UTC) X-FDA: 78837164658.11.548594A Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf13.hostedemail.com (Postfix) with ESMTP id ACAC5105338E for ; Mon, 22 Nov 2021 16:54:26 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id DFEFF1FD39; Mon, 22 Nov 2021 16:54:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1637600067; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lC1y7/6XwmZKnT4bImFqmCWjnQi+LoIW+FctDlpkILs=; b=ci1wPlUVm4xzwrECdtfjDFXPnlOQ0wLLLkZ4jDIs1Nli4RF+0szVwHv1NQPjXCIPf+xX6b o0jW2aX/QsxMvfwWx99maXWkCL7BvfifPm5YciHInPk0yPPpO2dJO90GZB99XOi2zz/cqO Uuzos5pZ1sGZZCXtQqVPkNXafYaeWMo= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B0139A3B85; Mon, 22 Nov 2021 16:54:27 +0000 (UTC) Date: Mon, 22 Nov 2021 17:54:27 +0100 From: Michal Hocko To: NeilBrown Cc: Matthew Wilcox , Andrew Morton , Thierry Reding , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] MM: discard __GFP_ATOMIC Message-ID: References: <163712397076.13692.4727608274002939094@noble.neil.brown.name> <163727727803.13692.15470049610672496362@noble.neil.brown.name> <163740548025.13692.6428652897557849182@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <163740548025.13692.6428652897557849182@noble.neil.brown.name> X-Stat-Signature: rgs54c9a64mudh3ah53cb9mxiq7uzzwq Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ci1wPlUV; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: ACAC5105338E X-HE-Tag: 1637600066-116345 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 Sat 20-11-21 21:51:20, Neil Brown wrote: > On Sat, 20 Nov 2021, Matthew Wilcox wrote: > > On Fri, Nov 19, 2021 at 10:14:38AM +1100, NeilBrown wrote: > > > On Thu, 18 Nov 2021, Matthew Wilcox wrote: > > > > Surely this should be gfpflags_allow_blocking() instead of poking about > > > > in the innards of gfp flags? > > > > > > Possibly. Didn't know about gfpflags_allow_blocking(). From a quick > > > grep in the kernel, a whole lot of other people don't know about it > > > either, though clearly some do. > > > > > > Maybe we should reaname "__GFP_DIRECT_RECLAIM" to > > > "__GFP_ALLOW_BLOCKING", because that is what most users seems to care > > > about. > > > > I tend towards the school of thought that the __GFP flags should make > > sense to the implementation and users should use either GFP_ or functions. > > When we see users adding or subtracting __GFP flags, that's a problem. > > Except __GFP_NOWARN of course, or __GFP_ZERO, or __GFP_NOFAIL. > What about __GFP_HIGHMEM? __GFP_DMA? __GFP_HIGH? > > They all seem to be quite meaningful to the caller - explicitly > specifying properties of the memory or properties of the service. > (But maybe you would prefer __GFP_HIGH be spelled "__GFP_LOW_WATERMARK" > so it would make more sense to the implementation). > > __GFP_DIRECTRECLAIM seems to me to be more the exception than the rule - > specifying internal implementation details. I do not think it is viable to fix up gfp flags to be consistent :/ Both __GFP_DIRECT_RECLAIM and __GFP_KSWAPD_RECLAIM are way too lowlevel but historically we've had requests to inhibit kswapd for a particular requests because that has led to problems - fun reading caf491916b1c1. __GFP_ALLOW_BLOCKING would make a lot of sense but I am not sure it would be a good match to __GFP_KSWAPD_RECLAIM. > Actually ... I take it back about __GFP_NOWARN. That probably shouldn't > exist at all. Warnings should be based on how stressed the mm system is, > not on whether the caller wants thinks failure is manageable. Unless we change the way when allocation warnings are triggered then we really need this. There are many opportunistic allocations with a fallback behavior which do not want to swamp kernel logs with failures that are of no use. Think of a THP allocation that really want to be just very quick and falls back to normal base pages otherwise. Deducing context which is just fine to not report failures is quite tricky and it can get wrong easily. Callers should know whether warning can be of any use in many cases. -- Michal Hocko SUSE Labs