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 3DFC2C54EBC for ; Thu, 12 Jan 2023 08:11:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B156E8E0002; Thu, 12 Jan 2023 03:11:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A9DEB8E0001; Thu, 12 Jan 2023 03:11:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 917AC8E0002; Thu, 12 Jan 2023 03:11:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7AB958E0001 for ; Thu, 12 Jan 2023 03:11:11 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 40FEBA0843 for ; Thu, 12 Jan 2023 08:11:11 +0000 (UTC) X-FDA: 80345426742.01.1E7BACD Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf24.hostedemail.com (Postfix) with ESMTP id 6E748180006 for ; Thu, 12 Jan 2023 08:11:09 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MXQcfGJt; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673511069; 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:dkim-signature; bh=g3rOVtr3FiiKyQNYoIzTg/bnyNbi0bomA2m3YXQL33w=; b=G57SQ4BjJoaJ0nf75vc/6wEghBoEIte+aFl0qCJQ9zn64kZoOnYRqyJXr9SA5NiBrFBE8O DCzmsNJHtx/tvkXQAPGnbcqMnsMG1K+9kJ6lEVBM1JXcXpGcT+2j5qeiqjG1ITjufDrUR/ 3t5F2LrfbpZWErqDnwzEQDwIa6HpTwI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MXQcfGJt; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673511069; a=rsa-sha256; cv=none; b=7NrNF5+FbcyiycTLK8hOblMEKZMrR/+J9qAxcfqtTp8el5zYIqp7PzBQFkVVpp8uaWt6t5 IfQmnrlYh2zyIU0sW/NS3bwzM64uQth+8Yhg7QvqNALtvfuXnvBK4oagAm7/92oab8IewA cvL/vohg3RvxBPyxAA6Oc1m2yKMPuKw= 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-out1.suse.de (Postfix) with ESMTPS id CD5243F60C; Thu, 12 Jan 2023 08:11:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673511067; 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=g3rOVtr3FiiKyQNYoIzTg/bnyNbi0bomA2m3YXQL33w=; b=MXQcfGJtyiYGn9YKNiZfgcR6UavUB8jL8lrmiMtqR5MAAPuSmslm2tPu1u2O3i7WdJc7xf fgiRDb2OA5aUFeAi8O4AyRa3VF3VNQJkGaQxYiw7u47jzOTjWXI7csyGvxHITikyKaXi1M MRzCvMocbBP6zr3ga7ziGR4sfiNy87M= 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 ACB80134B3; Thu, 12 Jan 2023 08:11:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id jyjfJ5vAv2NJaAAAMHmgww (envelope-from ); Thu, 12 Jan 2023 08:11:07 +0000 Date: Thu, 12 Jan 2023 09:11:06 +0100 From: Michal Hocko To: Mel Gorman Cc: Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 6/7] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves Message-ID: References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-7-mgorman@techsingularity.net> <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6E748180006 X-Stat-Signature: wswj5x7sjn4jsbexbf7jcbfibpmfnh87 X-Rspam-User: X-HE-Tag: 1673511069-440371 X-HE-Meta: U2FsdGVkX1/iGJ3DCjjftaDjatBOcBN+a1ebisZkyz+ze5KFd2FMCSBGJujrqvHw6DsTjhhdm2FMEU4JFJdagTtSDB0e1xGwFvZRrSdzDeHo1vUgB/aEwhjTygjWQXV81CgDfXRHAsYPyFMd+GoDxaT8T3aw6ZRXStXQF2MnfgIgMAriNHiojP3osfcZ+a+M14hbPPJ0qcV/g5HxR2llAWSaVC+tTW/kPgVnY5aQfeiy+ivUPqW8VrYUIfCuerybpb6ZBHUujHX091h0OywRl4eqgY08LR0T/IIempvB7Kkitf+F55baVh03OTmRAvJOn3yzqlgb9xKE31O+41/p1rORE1wJwrIerecyry7Lvjkb4a/XyafB81gxF5JHlMrDtqlj7reBm8KeMt1Fi3h172PpskUPrGiM1XNLh3Ku6ApwdsyxoBr0t5dHCO3UwB7KGT5pGcZSs8/KErbPvOrfUEXoh+Ik0l0cJcNMdo76T9kpITXBto9z0HK6fgoeLJO8mogcAPQ74lQvAIlIylBlyBx66W4txJIvYaI6ePHuiR3eQFCnYNe2OnwpwfcKwZdGyukofqv4/UjkQQBSn/bS8eLXqJFJmutlaud4m8UJAARX2imBqsXFKNRmYVQXSujkz9kYd303UBefscHGcTaYgewE1N+iJRLvw0irshzs/ANNd6EUKcCexDi4jDFH0bShZesvSGmoh9AHDVa3b5XkBQQnyYGylX3mwhOfDbEcuo4HnPe3okj29jGAV5p0aIne5XG/u5N8aq/gmZyNno0PcnoCO+6ur3OdkXGWwES2DrRfDzNOjxiC6EnIe1+GzbgvchpDz2R3R6AmQl5S5maQIi6DNV/XUYpq9ACQnRFYdDtWJ/EeTK7bSX1LJ1z0ndRe0TKrPP7Yw4V9oXQbAvMM3xNQLtIaF2SAjCIt2r4hSxM96Htvb84PF+zQxrBI0+hoKjvS9oaQ5vHD0IoHo62 ew4L8oG2 DCdwzkbgXM4G02R4= 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 Wed 11-01-23 17:05:52, Mel Gorman wrote: > On Wed, Jan 11, 2023 at 04:58:02PM +0100, Michal Hocko wrote: > > On Mon 09-01-23 15:16:30, Mel Gorman wrote: > > > Explicit GFP_ATOMIC allocations get flagged ALLOC_HARDER which is a bit > > > vague. In preparation for removing __GFP_ATOMIC, give GFP_ATOMIC and > > > other non-blocking allocation requests equal access to reserve. Rename > > > ALLOC_HARDER to ALLOC_NON_BLOCK to make it more clear what the flag > > > means. > > > > GFP_NOWAIT can be also used for opportunistic allocations which can and > > should fail quickly if the memory is tight and more elaborate path > > should be taken (e.g. try higher order allocation first but fall back to > > smaller request if the memory is fragmented). Do we really want to give > > those access to memory reserves as well? > > Good question. Without __GFP_ATOMIC, GFP_NOWAIT only differs from GFP_ATOMIC > by __GFP_HIGH but that is not enough to distinguish between a caller that > cannot sleep versus one that is speculatively attempting an allocation but > has other options. That changelog is misleading, it's not equal access > as GFP_NOWAIT ends up with 25% of the reserves which is less than what > GFP_ATOMIC gets. > > Because it becomes impossible to distinguish between non-blocking and > atomic without __GFP_ATOMIC, there is some justification for allowing > access to reserves for GFP_NOWAIT. bio for example attempts an allocation > (clears __GFP_DIRECT_RECLAIM) before falling back to mempool but delays > in IO can also lead to further allocation pressure. mmu gather failing > GFP_WAIT slows the rate memory can be freed. NFS failing GFP_NOWAIT will > have to retry IOs multiple times. The examples were picked at random but > the point is that there are cases where failing GFP_NOWAIT can degrade > the system, particularly delay the cleaning of pages before reclaim. Fair points. > A lot of the truly speculative users appear to use GFP_NOWAIT | __GFP_NOWARN > so one compromise would be to avoid using reserves if __GFP_NOWARN is > also specified. > > Something like this as a separate patch? I cannot say I would be happy about adding more side effects to __GFP_NOWARN. You are right that it should be used for those optimistic allocation requests but historically all many of these subtle side effects have kicked back at some point. Wouldn't it make sense to explicitly mark those places which really benefit from reserves instead? This is more work but it should pay off long term. Your examples above would use GFP_ATOMIC instead of GFP_NOWAIT. The semantic would be easier to explain as well. GFP_ATOMIC - non sleeping allocations which are important so they have access to memory reserves. GFP_NOWAIT - non sleeping allocations. > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 7244ab522028..0a7a0ac1b46d 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4860,9 +4860,11 @@ gfp_to_alloc_flags(gfp_t gfp_mask, unsigned int order) > if (!(gfp_mask & __GFP_DIRECT_RECLAIM)) { > /* > * Not worth trying to allocate harder for __GFP_NOMEMALLOC even > - * if it can't schedule. > + * if it can't schedule. Similarly, a caller specifying > + * __GFP_NOWARN is likely a speculative allocation with a > + * graceful recovery path. > */ > - if (!(gfp_mask & __GFP_NOMEMALLOC)) { > + if (!(gfp_mask & (__GFP_NOMEMALLOC|__GFP_NOWARN))) { > alloc_flags |= ALLOC_NON_BLOCK; > > if (order > 0) -- Michal Hocko SUSE Labs