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 8DDEBC46467 for ; Sat, 14 Jan 2023 22:10:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E623D8E0002; Sat, 14 Jan 2023 17:10:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E10E78E0001; Sat, 14 Jan 2023 17:10:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8C78E0002; Sat, 14 Jan 2023 17:10:25 -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 B77E08E0001 for ; Sat, 14 Jan 2023 17:10:25 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 75B0D1A07B2 for ; Sat, 14 Jan 2023 22:10:25 +0000 (UTC) X-FDA: 80354799210.23.715C35A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf24.hostedemail.com (Postfix) with ESMTP id 9AA0C180006 for ; Sat, 14 Jan 2023 22:10:23 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=PMBat9mn; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=mUIsUAbn; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673734223; 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=hpQd30hM5sD53/V055856NaFnEhJfkox4w8QhX+l1iE=; b=Dz0up19ofXzJKH8Ndj7pTp7//bhUqwlwtKtKq2ZCldlCWhASWxstQw33uJBEX3EtOwDiFR kH4ituW4YLLAc9qbO8CPSJdvRMQUyb3w0UuIWu8/BtIlyVCMhNgDsSDsgeWX34BJ5CnE0M WI7kEJuFIGJAPP4sN/FdrkkqMbl4vWY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=PMBat9mn; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=mUIsUAbn; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673734223; a=rsa-sha256; cv=none; b=Y7NHZU0SqXhErTGqCpwNgdRlgGjA4OFbFPsf5/3med19ZomxO9E8xMxJwJkWyKLmXY8WvV vL5p51G44xAUNhaIK63/SVhr7sMh+P8V6hC20udwHatC50W9wNaAMhoEWKuRHpMkr50uCG sWjoeQ+PB15eBcuYQciypJSskDL7T+0= 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 A52033EB26; Sat, 14 Jan 2023 22:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1673734221; 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=hpQd30hM5sD53/V055856NaFnEhJfkox4w8QhX+l1iE=; b=PMBat9mnVPH4n4Sh51IztkXT9Y6QlwS4xHm/fpdfBJ4vr62V4Ti2pjzya0owz6sW7BZ99E zDnaa13ZJYefw4uH5HB7FyoJY6euoP3Q3ruODzeQcyWT8H4phxORifgVkeFLfRq48eIKXK JR66dQtuWFJ+5ivcJ8CkscfqmlQSo2o= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1673734221; 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=hpQd30hM5sD53/V055856NaFnEhJfkox4w8QhX+l1iE=; b=mUIsUAbn4pnBlAU5TKwl3008gVwjhdIESKGp0T1k9Dp9WNXfVvYmylatWuFldGxWE/vTLO NPqFFfPORo+flgBA== 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 5ACAD1391E; Sat, 14 Jan 2023 22:10:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4FZCBEoow2NTEAAAMHmgww (envelope-from ); Sat, 14 Jan 2023 22:10:18 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Mel Gorman" Cc: "Michal Hocko" , "Linux-MM" , "Andrew Morton" , "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 In-reply-to: <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net>, <20230109151631.24923-7-mgorman@techsingularity.net>, , <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> Date: Sun, 15 Jan 2023 09:10:13 +1100 Message-id: <167373421396.4602.14376527067766958302@noble.neil.brown.name> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9AA0C180006 X-Stat-Signature: 7xs1e7bpuebscjh4h57cxetrrtb6fnr6 X-HE-Tag: 1673734223-95198 X-HE-Meta: U2FsdGVkX1/f3v8LVX3LlmloIst0SAOxWrmjvSKf/3JXXclDLEIOj0UwjFHYWeTGCpbX7Y40E5PQfsl9awzVZXbVNNVAzoSE2n/1NZcRThFemSAODHO8Px4uYLkJrfFT3X5BjW2eYkhb3SdBzO1N2lFxz4eH1pM/jWX/h8N1/UowABcRK59N4GW7+W3lz8yYkHNU+VbbKafIzESAEsNZxUWHF38wGVNnNNxrmCNrWN4ucg3cYJ2j48e/sgf68NFFaHFpW1+4PaXo3ygUlL/Rbo5pPdnM69T3LvDMXuSFy2VMchnzoO6xiK9qCj7J1Qr1pIKpszVlZeI7+I67+aQnGu2N/a+QtsdY6qxgpxUTmC1J/o8dYrKwW6HIQC7RHjeAmWdCm6a6/5Nd6jZ3wIKS9WgDX09hw9s7psNNW06pa6GR/8APZiioIA/Lj/fzlO9/q5qg7YK/yFILrU84b1lN9kD1nJ9gk/geOO29dQ4w3DvZEuwkxO2vMtutQ66b83NIkNHNQCeJ/NTeNV+na8IhtFcAIxWcTOgmgOtT2k3Zy1O4GWapRXoMeVULvTAHQm8JNSCyeH/QK0Kc/bfg0UypKhHOUMzhFoq2+JY8hCtITFNUl/RjL8Aeeq9j+pGxCYMLVNEsxX61R+Z6zyGIa2nv1/6hymO5koGm5sgDzpEwrzgYrA6S28n+//ls9h65kNXBdRwjgVjw4ngduatlsTZtNPOWoiJBfJXpeCAD8ncoFODsEmtZflfSrz8nYiQlbB4By3ua0vPjHZSUOKENKdMa37ZcCFBBv3aT4vUuuNZKxx/wzIL67gRziSvnOr8t1G1o5iLqMWn+6q44SL3IZpTZkzMWsoSBmOXTK519Sg8sWG5Pcv+nsetFc3JNqHiK5ihY1dkHVfDJt0CxappMlmav6vnbJWuOzH4CTFFF1AupeSto4QhLxXHpTLITOhpel50Uisrm9+sy2qi/aHe5wcY aCEvqnom v4VszmI4SW3HJf7InCag8coPY1IgFkKgRytb4 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, 12 Jan 2023, 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. > >=20 > > 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? >=20 > 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. Isn't that a distinction without a difference? A caller than cannot sleep MUST have other options, because failure is always possible. The "other option" might be failure (error to user space, dropped packets etc), but sometimes failure IS an option. So the difference between ATOMIC and NOWAIT boils down to the perceived cost of the "other options". If that cost is high, then include __GFP_HIGH to get GFP_ATOMIC. If that cost is low, then don't include __GFP_HIGH and get GFP_NOWAIT. I don't think there is any useful third option that is worth supporting. NeilBrown > 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. >=20 > 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. >=20 > 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. >=20 > Something like this as a separate patch? >=20 > 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 orde= r) > 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 |=3D ALLOC_NON_BLOCK; > =20 > if (order > 0) >=20