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 A5BA8C5320E for ; Thu, 22 Aug 2024 09:24:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A8866B0207; Thu, 22 Aug 2024 05:24:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10A8E6B0208; Thu, 22 Aug 2024 05:24:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2A0C6B0209; Thu, 22 Aug 2024 05:24:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B76976B0207 for ; Thu, 22 Aug 2024 05:24:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 587FDA8AEC for ; Thu, 22 Aug 2024 09:24:54 +0000 (UTC) X-FDA: 82479346908.19.FBB294C Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 415D940008 for ; Thu, 22 Aug 2024 09:24:52 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Dd2n5geC; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724318611; 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=526Ab/yRd/9DVE03lo/GCJKyCB+VQhiWKCsYcqBZPe4=; b=Xa5uQ1PYjGxH7iTPivf6NVs8XMJBNQLSvzgq6NtNedBZeU8tbP+1Lh+z5oDMdBBglA2WqL AnR9PEM7xSqxyD6voN5xJCLa19HdmM99bJMjgZXkAweDjAbzOgXGQ+JEJKNN55SxFheOlW JFXNhN7v4DAmgiPOxSV8F4qHG+jiLwQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724318611; a=rsa-sha256; cv=none; b=VyQgzXO5b5CdgSTiSL+DX/Iyh00sm9r+73u38sFjIvC70ZGA+MvO7RYHNamOQ91cHVTEI8 fMXVpmFib9B9pSqZB1xl01i1oVefr1f0HeH4oTP55muYr91nDEYhAbxL+nafX9qEWf9Lt+ hyyinqMWeBk7yeTQavtohalrRzUCD14= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Dd2n5geC; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2f15e48f35bso4583871fa.0 for ; Thu, 22 Aug 2024 02:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724318690; x=1724923490; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=526Ab/yRd/9DVE03lo/GCJKyCB+VQhiWKCsYcqBZPe4=; b=Dd2n5geCPhn0NMfZOItE+Ge5cI3mjM9rmy487NChkkCezedHlPAZDKiCAaym4Klr5X mP1KDDCpSHRThGxzsH7NqULVT8oJEvF3rtLCiaMLKRc7EbDjiyfRMPVDAVnPtzVNOIiD 5dXCEqXbkFyZQmgB4sWt150o5b9apOeA3AJAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724318690; x=1724923490; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=526Ab/yRd/9DVE03lo/GCJKyCB+VQhiWKCsYcqBZPe4=; b=QJ/rvID/gQDsGimu7HwZ8zoK2LpbHdiEFbTQiGFmaBpTn8mQVBaoLNDhES35GJYHk8 PnxFd2vd/TmGD49y+OaVcCiDwgwnGV5S/WqIm+ni+iDCXENhyIZ3uWuo/EVjyR6YqMfz Flz7H3WljNikkcwQnteHSbcSZrtftgkqfXHzW681EJ1NsLZix0YIZPARtMHRB6uEIWlR 7zMV9j8h7ip2U/OpjhomLjR8aFFyFUKfSqslnh8gMvVEdYAiifDrSesqwZdVsez2j24V PkQ5jRKAN8jTjzD1KhdDnJMtA+T1zL339ed58yaz0y4o4ii7noIC004BhEkiHgdFK20+ cpkA== X-Forwarded-Encrypted: i=1; AJvYcCVuboMd31B+HurtBlLf2aWbPh3+r2nFDzS55Ux3vCR5IjTNWvaOEeyZBxaBQAJhGuCpbt3qmbHq5Q==@kvack.org X-Gm-Message-State: AOJu0Yw+Q0b4d6Rvf6NLJQsMsFHPEebyLseYhxTPWTpDGN9C3TKQAkFX WrKcUe1nUjJvGjnTslBmZLbctuDd2bNpg+gmBzRHZRFfhQKt2uMA8N2xrvrCJ5Qj4Vw3t2k4wZ5 CARBMWg== X-Google-Smtp-Source: AGHT+IFTKMaQH+aRGtrqqVP9HGImS/UZHD1Omxif3Xo4mgDp4N5yKSB8r7cQuHgfIhkKfPY/4iic5Q== X-Received: by 2002:a2e:9f44:0:b0:2f3:cd3d:a5b4 with SMTP id 38308e7fff4ca-2f3f88edaf8mr26849641fa.23.1724318689641; Thu, 22 Aug 2024 02:24:49 -0700 (PDT) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com. [209.85.208.51]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a4c72a7sm663378a12.65.2024.08.22.02.24.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Aug 2024 02:24:47 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5becc379f3fso870122a12.3 for ; Thu, 22 Aug 2024 02:24:47 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWpGqGBlwf4pZ77mkR3NDqf5kozOGib5YDmsdK9vVUlYJXihmvuUgfUScKMWOCsFbO/YCLivNfMXQ==@kvack.org X-Received: by 2002:a05:6402:3487:b0:5be:de37:80dc with SMTP id 4fb4d7f45d1cf-5bf1f288a7amr2922233a12.37.1724318687086; Thu, 22 Aug 2024 02:24:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Thu, 22 Aug 2024 17:24:30 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Michal Hocko Cc: David Hildenbrand , Barry Song <21cnbao@gmail.com>, Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: a8i7c66ig8iqiammuuz5xfi67naaaj4u X-Rspamd-Queue-Id: 415D940008 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724318692-715407 X-HE-Meta: U2FsdGVkX18VOYHANmBH5BwXKRZH52ALoYqqYGIAQqAFmgSKPqFje90A+NYvin945H5d8/XrOQGYI67CYVJ0gIvETYsdsLtwwKEfGckINzhNjs00QGF2JZXvgAVfOSq/5cZRdrY9p3dHDR3bOvwoFxk6VakhwkijKDheXQFyMGr5c2niMmcmRIw3uB8JjuuQKbpU0rqlBvNeitoa69f5pwtFGFZCNP2wtnhIG3V86pq+S+g//zrE02b607NOBXcVdFt6Oxf8SxgrUn43EPbY/LDENRIqp2GGr+oH3Vn7W67QHank/tD+r34Yb3GidnaFSCIv3Sezrvn4GXbUZ+FbTLshNwXRcVXF0ExNGREhZf63dKop+DzdZIEhHjhr67SbydfkYy6kj3oS/q8h8d4gTmCDKq87PN46XFH/lOb6zplZzwyw7bAIOOUdrxUU2MFb6nd693jqiVnnakfZD+dBBKcvsYLUkjkPa4z/X8Mk+MSRcxyMNohCsdVH6hP2jvPOrI5LHyZDPmP+t67KN6lznFsxEowNEJSpDYlwNJ5kNkMpTVmFAckCK+fQx97+5RNrDvvhar6hqiTeDqt2oxaX+DIMEyRqpgOrQR4FcebWPy2Tg5bbMujOWOtAqsxpFP5v/Nw6Qtv7AcmT256A1q7zXqkqHBoDA3r10zOberzJ8Yu++GmOAY3ENw/WGAcokiQm06oKYZWmEt8A7h1tH/iXFvUi5SasQjrCAqk56gul+ulrn5IW5YtM7czVGqu/YFJuy+9jhlVHGh2yZmqiBlpyBg629du3n06dBu6+xuWTJU8DRIw+UzA/CPe3WAhqi0pPDTsaskWVOnzIfcjOY7iAtzgMRlQMimOhZ7ZslQbmjvC0d2FwquhPYXMneOIGQn9Btw3plYMogusq1GGLLmHDrgeU3ch29SphFBxbvDoNeppqIS3xwFOzPnQZkgTvzPxrJyD/vF7n27H9NdnPgfT 6IE841Pb pWhphcfsKPFgxCwhvpBmTa8gl6gK5OMkxz9uzbxKrFBGijG9om2xpDMvQ8u1CHJ5QpW/QZbDChuVbHzQhiL9I7Te2UBKiHygmNsbgYmxy63Ga/p+I/WLv7rOYRBsdIst41L0/+Jd4cfFAQ0zhIMpiDrkAqqco0tk5WdmbyW0RWFzNrdgA3dmgSveP3a5poc+04zxR+0Hi4bSP8lvEu5SEfiekdKRYyygyL+orUfQtgM096Ig4zXK/ssRnqCvSA/lFCphW/x0SezWnd/EHThe4TIrgE7Hyk8YS4IdJ8YV0UV+kqD1iKEe1DmO7kVYoo4mOOf2WS4rFhqaxbuXndIuJqKDB34GJokYXdHXi9gRDJ81V5quDjspCIaP4epIZx7heqiazCdg5jGquIq6CoCH5y03JWtDeFuN/lbD9R6Ji8er3b4V3oCankwO2oGnaQy24Og92n3Uqjicubgt4frcI0vzeTjd7otk7iLg5kaWrDhIhYw6z2B4WWy4amW1ymFMM6Z+sP8NeXj46fFwKmvneCbFiWwWTN4kvYANCeylcCyeJDKQR+XnkkLZmNSiGluhZzfolbL1IM9ugklao2bNyb5Fj7S4dZy+iTf8RD/SlvmNvezY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 22 Aug 2024 at 17:16, Michal Hocko wrote: > > GFP_USER allocation only impluy __GFP_HARDWALL and that only makes > difference for cpusets. It doesn't make difference in most cases though. That's what it does today. We used to have a very clear notion of "how hard to try". It was "LOW", "MED" and "HIGH". And GFP_USER used __GFP_LOW, exactly so that the MM layer knew to not try very hard. GFP_ATOMIC used __GFP_HIGH, to say "use the reserved resources". GFP_KERNEL then at one point used __GF_MED, to say "don't dip into the reserved pool, but retry harder". But exactly because people did want kernel allocations to basically always succeed, then GFP_KERNEL ended up using __GFP_HIGH too. > There is a fundamental difference here. GPF_NOFAIL _guarantees_ that the > allocation will not fail so callers do not check for the failure because > they have (presumably) no (practical) way to handle the failure. And this mindset needs to go away. That's what I've been trying to say. It absolutely MUST NOT GUARANTEE THAT. I've seen crap patche that say "BUG_ON() if we cannot guarantee it", and I'm NACKing those kinds of completely bogus models. The hard reality needs to be that GFP_NOFAIL is simply IGNORED if people mis-use it. It absolutely HAS to be a "conditional no-failure". And it needs to be conditional on both size and things like "I'm allowed to do reclaim". Any discussion that starts with "GFP_NOFAIL is a guarantee" needs to *DIE*. Linus