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 4B956C5479D for ; Wed, 11 Jan 2023 17:06:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 976B98E0003; Wed, 11 Jan 2023 12:05:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9251E8E0001; Wed, 11 Jan 2023 12:05:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7ED4D8E0003; Wed, 11 Jan 2023 12:05:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6F5918E0001 for ; Wed, 11 Jan 2023 12:05:59 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 44DCCC08DC for ; Wed, 11 Jan 2023 17:05:59 +0000 (UTC) X-FDA: 80343145638.28.D619D2E Received: from outbound-smtp29.blacknight.com (outbound-smtp29.blacknight.com [81.17.249.32]) by imf07.hostedemail.com (Postfix) with ESMTP id 9EB754002E for ; Wed, 11 Jan 2023 17:05:56 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.32 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673456757; a=rsa-sha256; cv=none; b=XMCUFJXUJJIauoBVfi2Y0W3uZly48zj1+bbDNESJDEvFVzJYv+u1IVwNQEfARUX6Zk9EGb 8SIqjK3SriyPHXsB8LOHyoVEcVAV128RVtOP9GZafHnQFZn4OAifYqH9Z+LVC0HIaGKNTP pILtED+a+bt48q8YEfV8Zl1YJdW3Kew= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.32 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673456757; 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=XmNMonbToSMFb2w+Qpu4sYehcaWkd0vpFVETZbzGeLE=; b=vpyXRanvrX3g5L9T3+ydSMW+27/lJHJaWJ6gAUviKnWUAIwq0EZ+WRpxbUnO64WYBs7GBZ rDz3gCRri68xIhxCQJitISVwYCihHijYhJuPaTjqFl1+iqbDahCK5DWga3E2Yp3xueo1wn 0OVp+hhs9+X5GOR2EbjXGBD7wIz+kSk= Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp29.blacknight.com (Postfix) with ESMTPS id D9A00BED3F for ; Wed, 11 Jan 2023 17:05:54 +0000 (GMT) Received: (qmail 6090 invoked from network); 11 Jan 2023 17:05:54 -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); 11 Jan 2023 17:05:54 -0000 Date: Wed, 11 Jan 2023 17:05:52 +0000 From: Mel Gorman To: Michal Hocko 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: <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-7-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 9EB754002E X-Rspamd-Server: rspam01 X-Stat-Signature: hda5fo5euxogiskhrqfiwgjsfu67rb3w X-HE-Tag: 1673456756-297786 X-HE-Meta: U2FsdGVkX1+JKgMC6v4xJ6bo4CKNmdZo+PWPlEvATAjpcCxLs2Pa9cUgIvhD2nH7z6HTDe/eIkhzXAtg4MWl0D6Y2hMUbrhKH4yAOfWGdoulMeHrtID8F784AnAq7T84172aHOBMiW2H+v4dQe0DnvhaW7+xrAzlWE1VGuqPdj6sl9s9BeHYv9oeOHWw+KrD2/qx58/CuWwx3CU1oh4jR9W0RGsewFUu7eNq89vdV9LKys9T/bPKMsX6zahAL7ouaRgHZaU4/YCJZpxCZ/66BJNl9jQDPgvWPY8KHkJkZxfZNYsMUBcr4Tfh+eFF9mVdHWKQdnedtO9lQVVw6BZXXrFbCK+C5ltfrn35v7BVJOY4pQMf0Xu/X6DHkNQkzKVabf7unmDDu+espK700gRIqmRSp3D9ASvIactBqE66IzJ+ODXxGBT/87dilH6TWNIaetgmhwDojEiJwTEM/x2BNcm0SJ3WWx5iT0Uh8wFlX2GDge2oemqj14w4D+8hY+wM41XoTFAwZcqczTqfT43huDiF8W6kUkivYJzheOkLwJ9o5vO/lrtP255rb2V7Sh8MO7otanXNHgZfT14TzYqUE1AtgqDgbRJh7nVL0o52hyqLpNW4nA0Woe+b7z8ytBE+9fmd062k0MczOZurpX+6wrAaj5eCJGWsh3qCggrr2v+aWeJF6G0zQzmt1VPMm3j2+e0fzsMdetNrgIfyNf27ckJA1EpXK236BBVAcl4aHdUaU1sCX5GQDcrk/xrAeblY4a309z63tKuEQsCYPz+K4VuA/sHGvRLtEaYNW3WMKcLQcgrYdw5I+4uOzOQzAPeUkjmn32gttmA4/1v4OwR/HzgnRPzk2+ZrU08C3nD5khjP7LAjbfxeEWM0di38WWuKon82IfD9dPlEkmaKsJ0/pgFUkLD8gDlInMWy+Sw68zgCJT7sfVHBh3mUkwS2KjWPEmB8dgOTGWHxXG5yzcm tEqgMuBF 4kP5hy1i7FDt0LhUYC0CdeHyOYA== 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, 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. 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? 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)