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 59CFEC54EBE for ; Mon, 16 Jan 2023 10:29:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF7FB6B0071; Mon, 16 Jan 2023 05:29:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BA7AF6B0072; Mon, 16 Jan 2023 05:29:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A96276B0073; Mon, 16 Jan 2023 05:29:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9B7D96B0071 for ; Mon, 16 Jan 2023 05:29:29 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 58F531604F3 for ; Mon, 16 Jan 2023 10:29:29 +0000 (UTC) X-FDA: 80360290458.18.E2F82ED Received: from outbound-smtp19.blacknight.com (outbound-smtp19.blacknight.com [46.22.139.246]) by imf01.hostedemail.com (Postfix) with ESMTP id 91A104001C for ; Mon, 16 Jan 2023 10:29:27 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.246 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=1673864967; 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=19b/mojQIDsPKlqpIIjjWAWWSQXxwAsQ98gCJErtCqc=; b=X/QJkr+CvQIhVWa+ntoTPwU2YQeXZNf4prILuBObYB/2AMqkDu+yaEYz3Sem0vvy7xR/GU o7Fj+enuYyd6TZ2EBIG68PvQuOh0eR0pJY0yUWisbeAO2VR8vx61HxZOxYNGI9foi4tr88 +5LITeraNUrlHv1I/mlQcOWeYN24cz8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.246 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673864967; a=rsa-sha256; cv=none; b=7YDHqzdSG744+7Glc7IV8tJQ16LsQ/V0gIDKEG0EOqb2R7gE21kE/2pG/fw9XwD0PT5QXS JU6qclkWeiqTzGcSLfrHLPTQS1s3iYtCKPDY40n2C4fsE11vXILaZ93OcNVz2/MD/OIEq8 P/oo2NMfAJldwhtw6gK6IGEDmgFPE4E= Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp19.blacknight.com (Postfix) with ESMTPS id 0D8C01C39F4 for ; Mon, 16 Jan 2023 10:29:26 +0000 (GMT) Received: (qmail 31739 invoked from network); 16 Jan 2023 10:29:25 -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); 16 Jan 2023 10:29:25 -0000 Date: Mon, 16 Jan 2023 10:29:23 +0000 From: Mel Gorman To: NeilBrown 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 Message-ID: <20230116102923.krilmcwrclshbm5e@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-7-mgorman@techsingularity.net> <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> <167373421396.4602.14376527067766958302@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <167373421396.4602.14376527067766958302@noble.neil.brown.name> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 91A104001C X-Stat-Signature: k5qyz4fzgigxiowr9khbuhqir9ram8gr X-HE-Tag: 1673864967-819882 X-HE-Meta: U2FsdGVkX18dQbgsPXczcvQI0qkZLtelSx+YIDZxJczt1uzajuaneCQw74/Yr8AUncOW090Xv18Lv2VF8Lkp5oswqmT4m7CUDflBVAQdJypbm9JPhqsd/fL1YJGDh710nwJnOCJQxWdJcEcDEGyCTwUVEdAteA4z+xQIkO/sYMFlpzdSygl41QwMyk06pKJElxeCmUZprmBZHRkcGvVxSSM5i40ja2/rauiwZtltYAwg8nWNf0qH2gN8IO+ZrGdOUPebEw0GSw7BLHtEsY5pA3ZqTWT1zPD7TrAG0pPde4PF5A2aRRsZxGpF5xE02L6uXtyRmII+AgMeJJyrY8ZaoRJz3tuLpjjZ7K3zgCdrKcG7zO6+BAJZGYKQBlboZOi0mWcaDbhsf51nwEeGGJYRsmtn37bYKgZNsk4lJo7aQDXIxp+rs1U4TsirWvMmrdAOKVJs42lkVOQr9sulcr+VpMDX65ldrWxuJSE+4JaBUwyffBML+dgoitPUq880ylQeRvwAvS3GJzKMPnTLclLZ62kPJDbuEb2j6djeSgC/NNzyToAdl+tA8krad3JNtMUApfE99/KeU+Hpi22lvCWiBHS9GwYstNjniaFVCKx1wRNVCICWEtUC4W3SXduIRRHHz29omal2NrNSx07kETjjszO6Z9dFQvwDzrwNrViT24tRV9wvvFO0NcXSBoeHHPaNGchs3wGyRa1Wp4sdFkCh1A84BbVdaPw1z5CmZ4ZHLphsEmc00byaBJXiAvZu8qCJf2hceforvWtxB0GVYxXqBrYFvyiGrbcHeQGTuBSS32YQogTFCNh217iEalPt2FhBgObn6vnVht0Rb5DgMSF8HpeUpeoB1YPzzgSmLTOD8A7XNS+FH4maj/mWnOvR9QqIS8AUUsamrKm1u6ZjmI8IeW0qg8bUWZF9irvXJ0ishy6cjesxR24HXvt9sSj/r79cN1ObBpkZm8Ci3YXcvL9 vyDO920R +n/C30n6gWHvXMUuvQj2PxBC6MprdWJomRMeT 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 Sun, Jan 15, 2023 at 09:10:13AM +1100, NeilBrown wrote: > 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. > > > > > > 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. > > Isn't that a distinction without a difference? Ideally yes but it's not always clear what the consequences of failure are. > 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. > True, but it varies how gracefully it's handled and there is some cut&paste involved and other cases where the GFP_ATOMIC usage predated the existance or awareness of NOWAIT. > 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. > Again, ideally yes but not necessary true. It depends on how careful the caller was. The core appears to get it right in the cases I checked, I'm less sure about drivers. > I don't think there is any useful third option that is worth supporting. > That's what we'll find out over time once the series hits a released kernel. -- Mel Gorman SUSE Labs