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 3B35BC3DA7A for ; Fri, 6 Jan 2023 09:35:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29DDC8E0002; Fri, 6 Jan 2023 04:35:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24DC58E0001; Fri, 6 Jan 2023 04:35:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 163F08E0002; Fri, 6 Jan 2023 04:35:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 05C848E0001 for ; Fri, 6 Jan 2023 04:35:32 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BEEB816067B for ; Fri, 6 Jan 2023 09:35:31 +0000 (UTC) X-FDA: 80323866462.04.1616A9B Received: from outbound-smtp22.blacknight.com (outbound-smtp22.blacknight.com [81.17.249.190]) by imf10.hostedemail.com (Postfix) with ESMTP id 1A185C000A for ; Fri, 6 Jan 2023 09:35:28 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.190 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672997729; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vp0tFF8JO8nH2VBvMDQhdtgp+NoGLXyG2XI3+WXN+30=; b=Dbd86khBATz+xnL17TwkStKTaHza2yRBItbcHqpsabFsolVOqWoEZ2mwUyVpVREhQmcPPD DQsHyzmu13WYOn/oV3F5p19Lm9t4VM/JiEYVNMK5nBHC12cOu62LnF+hqaoE9U1xd618j7 2hGmSnpj9zGegdZ0rkgHXkvzT4POpqM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.190 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672997729; a=rsa-sha256; cv=none; b=Xq6xPsrCwimGIiuFrpMkKIveaUTqNcL3Gwc4AclQ/wNz3jC1U/yOxDyh6FE3KbXWx7Ii8V UbvJlzKKT/j7dfYJ549aVxQoTE3llpxZ1nVi0lukOecHxHCa0wojtiNFwZPHroQoYRAENY lN4UoNUt2UoYprw6vYgB2R4/7Bm+1uA= Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp22.blacknight.com (Postfix) with ESMTPS id 36B4FBAA84 for ; Fri, 6 Jan 2023 09:35:27 +0000 (GMT) Received: (qmail 300 invoked from network); 6 Jan 2023 09:35:27 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 6 Jan 2023 09:35:27 -0000 Date: Fri, 6 Jan 2023 09:35:24 +0000 From: Mel Gorman To: Mike Rapoport Cc: Linux-MM , Andrew Morton , Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 6/6] mm: discard __GFP_ATOMIC Message-ID: <20230106093524.ck5otyaopd724een@techsingularity.net> References: <20221129151701.23261-1-mgorman@techsingularity.net> <20221129151701.23261-7-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1A185C000A X-Stat-Signature: ag7nhuy8eseetwgbk7qbckd7xa3j3a5s X-Rspam-User: X-HE-Tag: 1672997728-269425 X-HE-Meta: U2FsdGVkX1/9eGGBFvG6uKrVZ632NJW/Ekj+iB2Gx3u5lSTPuSDayE2tVc83+qQhAhbwjgHjbIibtyoxHDwdM6ZuFStUTRE3j01sBp7llq64YGE8BBFkfSoQLrSNYUqPPyLSZUAbvMK1Jc6rRhOs8PqnklN5BYMZ3Gaoz+DakC3LAnBDiw3thnlhmvbBDRvew/jgHAOoWSq19pBGsmQGBD8xLv7UgMSPH9dXuylc5/egghOXAVz2MDMh/tEwo2Ko1TQoIaGuPdq/pbDBEZVUO46pLpOiQjvUW9U5SvTQNKNr3HM/Y1pWEnuBlVXivLrLx2nzbXg2KQWssSiFq9Vvuxpqd3dt6cRMkMqgfrchcgc+TUdXCjIxi8cA0i/EDBR+cp6mhXsN6LDIT7HW27NWhpiy+2dbe3xhqRRZPBsXE83Ks55m7laG2DFpa8SKWOmmpZ+KghsZw2qJLCfyyb2Rjv6WEgl3IfiVTuJm2pnAlcCKrh6Z3DAW18xqfRWxGsNoBY4p0SE8vSSSvlZMOTdqQXlHJ0bd7mZaUACHY2OPeO/YRoItWXrwTxkpkW4WWfpB5pp1iKW1IIPweK4kkeAwSaCzqxEutIw+DzYY6JI9UM24RchwYjUx4CTD7IgzgIqxRc3OzBo0Q+qK4p1PMKC5M2yxrt+4AZuxv7O+sJMSoxuYrSsDgrw36ti6HkaaUt5RmGd5YvcY2MKVcm8+InhIeTDNHFVUEGbiA99y0O0/7aTiiyq3OdBJU77rf4nhrx7+sd7ONt9J9JIGdkaTYM3w0oqyU8jx2AFhikR/X0+Q41IUnGlekltuGNfWSTE2JCftnU1EJk8dLTqIarXvtYFjfsTrtv28/ArWMJ/iQiiUeXno8wP45D9vd6pYdBlTObAB/OMn1CxemSvmDsnrWNfWyVDRkOmxwGwvBgO4qeEFioCf8dwt1iCn4HD7mxSVRMaEWnKJzRa7SFUXqwjGYn9 Y4A76po4 dc/SQ2zoka0OQeo/WPmC8sbeGZw== 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, Jan 05, 2023 at 03:49:44PM +0200, Mike Rapoport wrote: > Hi Mel, > > On Tue, Nov 29, 2022 at 03:17:01PM +0000, Mel Gorman wrote: > > From: NeilBrown > > > > __GFP_ATOMIC serves little purpose. Its main effect is to set > > ALLOC_HARDER which adds a few little boosts to increase the chance of an > > allocation succeeding, one of which is to lower the water-mark at which it > > will succeed. > > > > It is *always* paired with __GFP_HIGH which sets ALLOC_HIGH which also > > adjusts this watermark. It is probable that other users of __GFP_HIGH > > should benefit from the other little bonuses that __GFP_ATOMIC gets. > > > > __GFP_ATOMIC also gives a warning if used with __GFP_DIRECT_RECLAIM. > > There is little point to this. We already get a might_sleep() warning if > > __GFP_DIRECT_RECLAIM is set. > > > > __GFP_ATOMIC allows the "watermark_boost" to be side-stepped. It is > > probable that testing ALLOC_HARDER is a better fit here. > > > > __GFP_ATOMIC is used by tegra-smmu.c to check if the allocation might > > sleep. This should test __GFP_DIRECT_RECLAIM instead. > > > > This patch: > > - removes __GFP_ATOMIC > > - allows __GFP_HIGH allocations to ignore watermark boosting as well > > as GFP_ATOMIC requests. > > - makes other adjustments as suggested by the above. > > > > The net result is not change to GFP_ATOMIC allocations. Other > > allocations that use __GFP_HIGH will benefit from a few different extra > > privileges. This affects: > > xen, dm, md, ntfs3 > > the vermillion frame buffer > > hibernation > > ksm > > swap > > all of which likely produce more benefit than cost if these selected > > allocation are more likely to succeed quickly. > > > > [mgorman: Minor adjustments to rework on top of a series] > > Link: https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@noble.neil.brown.name > > Signed-off-by: NeilBrown > > Signed-off-by: Mel Gorman > > --- > > Documentation/mm/balance.rst | 2 +- > > Documentation/core-api/memory-allocation.rst needs an update as well, and > there are other mentions of GFP_ATOMIC in Documentation/ > What part do you think needs updating in that file? There are two references to GFP_ATOMIC in that file, one about accessing reserves and another about non-sleeping allocations and the accuracy does not change after the series. If anything, this statement should change because it invites GFP_ATOMIC abuse for spurious reasons * If you think that accessing memory reserves is justified and the kernel will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``. There are other references to GFP_ATOMIC in Documentation/ that are are a little inaccurate but not in a way that is harmful and is not changed by the series. For example; GFP_ATOMIC requests are kernel internal allocations that must be satisfied, immediately. The kernel may drop some request, in rare cases even panic, if a GFP_ATOMIC alloc fails. This is a stronger statement than GFP_ATOMIC deserves but it's close enough in the given context. -- Mel Gorman SUSE Labs