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 69948C4332F for ; Thu, 8 Dec 2022 18:17:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E51198E000D; Thu, 8 Dec 2022 13:17:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E01238E0001; Thu, 8 Dec 2022 13:17:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEEF48E000D; Thu, 8 Dec 2022 13:17:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C0A4E8E0001 for ; Thu, 8 Dec 2022 13:17:53 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8ED1D1A0EA0 for ; Thu, 8 Dec 2022 18:17:53 +0000 (UTC) X-FDA: 80219947626.26.44C5859 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf03.hostedemail.com (Postfix) with ESMTP id AEDA320005 for ; Thu, 8 Dec 2022 18:17:50 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1KSv5ZPi; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XBUKp0CH; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670523471; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WOpbqhi4deoSPQ5gjb+StOVqnfFIV+93wgbp/8W+O+E=; b=3s+mJXtKPNjlz+UldkjVePRPAa5vy5pICDIrvI9c1Z5in+3Re5zG6jUzjfxBcgmxTdmF17 6YWM/hRRw05m935mnoLvVGpnyd3ea0mhtAvLtzRa/kriYVq/NPAUD9oUe49jwVHqU3KoUb BiqeaX1HLZwmy1rvSL0OhXZVl31TpaI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1KSv5ZPi; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XBUKp0CH; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670523471; a=rsa-sha256; cv=none; b=IJRvyXs+RGSuYyBSH9EmQNCHxp8NqeohUzJGHBPasBzN0gCmq98YWXPSyHtfb3LeIszjsy g0+l+FdJJcvPEYEy1nREfsbtVbYs0tgrk2KCUJsokD+EL0LFXonlvbaOxa+MyZznilbbkT FT7NT8xzY1mXHCsPvDvYLSL5yDxWWr4= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4E039208C5; Thu, 8 Dec 2022 18:17:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1670523469; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOpbqhi4deoSPQ5gjb+StOVqnfFIV+93wgbp/8W+O+E=; b=1KSv5ZPicrjspUpQgVfP5D7FhQYHnvc+FaGZQR6RMgEY7A+G91LNeXkAGT6s2lWhUvGno8 BGlQZUw6ccq1iRdRElG7L4tiyQnPAFRfqlOe6HAE8poCMsz82FtoQbFN/wTIPc+RkGYR7F t7Ur75e/ldHF7e3LbCA8DFm9oDdX16s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1670523469; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOpbqhi4deoSPQ5gjb+StOVqnfFIV+93wgbp/8W+O+E=; b=XBUKp0CH5acsWj28r2DVmK+P6suJul5ddvzmk9HmNOLh8EEVKxMDHMf6Wd5noRThT5bVGp eIIDqVE456wlWLAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2922D138E0; Thu, 8 Dec 2022 18:17:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 8c0mCU0qkmNYVgAAMHmgww (envelope-from ); Thu, 08 Dec 2022 18:17:49 +0000 Message-ID: Date: Thu, 8 Dec 2022 19:17:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH 6/6] mm: discard __GFP_ATOMIC Content-Language: en-US To: Mel Gorman , Linux-MM Cc: Andrew Morton , Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , LKML References: <20221129151701.23261-1-mgorman@techsingularity.net> <20221129151701.23261-7-mgorman@techsingularity.net> From: Vlastimil Babka In-Reply-To: <20221129151701.23261-7-mgorman@techsingularity.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AEDA320005 X-Stat-Signature: 89f969g3rhgce8dn67hannjprtpstnqx X-HE-Tag: 1670523470-626944 X-HE-Meta: U2FsdGVkX19IQq+4crlTTc/mPjxLCJGFtEwVbZNGE1FTDzk3910J1GQSB1au7nMxb3R9ckhNg1L5pwcaak//6+3cpCpSUY41Wb/+TEOTW4HuK8rVzT47xxGAk0WHdf7jsOyjMFne2pn/R4GEnKdTEZ2HgTiqu0KlhzWoDA4i48TBbRQqo/VNKa1rhqQ2T02kSdajJXoZ4zHbyi3Rdks2dgDtqHMwk+PQoRY2XH75TqbVBnuduCCp/PuXqglD+tQzhZkaRafkSny1fjFHieoPvSf/cSLQP+AGKTgUHpm/4ciZ5mHzdSYlZ70auUACp41WN9VC74JKhBvMU7KVXdSUXEg1Jn83BHbuHMZ0O/RtH4+z1ZcfWRErCqAI3RkGer4waGrakHeZEx4olmuD3Ab1q9yF3pjuZf+OEWsMj+yQZ4ZXeLYZD5cBOMLcP0nEi1LJ/Gl0U0cBllS9XyrGp9YGpAs/MmwY5XwGzgail0PwgWt08hRFeUK5gWEnKfRnubLaO9vS01vHjJBUp3IXeCdkxLW26GUPCgNcBHAmkEbQmrkY31pIKl+JygqHxlonR8vnYWotHebKWwGQ0wYv5w5bFNclDMc6rnX+0ATmy61ODZL5qExJdHk5qwjDXrp+8tmly9KkaCH7yYlxNgSpFGUV9fDc0fqRTyUAlnSJXG0shvpzwN0/ooz0amG+4IYOq+IjD2mI3mmBIaKgTGw7ZjXu9yGEQJhAkRmI6E2qoxAgCzjHzJ8SKWpjFf4xp6KK8u4bn/9wkq79IFTbYrTX4eYpb/pUQjXRRA8whpsIN9p1c+0euID+vlfLEYKA5aGjsg3r7n6H4C72EoeXgFliBUsVOzrUq12gKuiyOqy2fo0/ypPkMhjGZckdp6Qk58NfmiCvplDfJawx9jdC5GfV2wor7US+Q4oEyTa6G2XNtETMAsszNZp2YMtRvdcMTo9STnnDusbMb81rECt/198OwIu km4wyMZg eAIk30kCdCsE3ADfdc2ZESmiov5OFjqe+sfkkxIJsyCCbt/21joKolVyLdA== 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 11/29/22 16:17, 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 Acked-by: Vlastimil Babka Just a nit below. > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4081,13 +4081,14 @@ static inline bool zone_watermark_fast(struct zone *z, unsigned int order, > if (__zone_watermark_ok(z, order, mark, highest_zoneidx, alloc_flags, > free_pages)) > return true; > + > /* > - * Ignore watermark boosting for GFP_ATOMIC order-0 allocations > + * Ignore watermark boosting for GFP_HIGH order-0 allocations There's no GFP_HIGH. We could either keep GFP_ATOMIC here if we want to talk about the high-level flag combo, or __GFP_HIGH if about the low-level detail. We're deep in the page allocator implementation so the latter would be OK. > * when checking the min watermark. The min watermark is the > * point where boosting is ignored so that kswapd is woken up > * when below the low watermark. > */ > - if (unlikely(!order && (gfp_mask & __GFP_ATOMIC) && z->watermark_boost > + if (unlikely(!order && (alloc_flags & ALLOC_MIN_RESERVE) && z->watermark_boost