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 35D7CC3DA4A for ; Thu, 22 Aug 2024 09:08:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7E4F8001F; Thu, 22 Aug 2024 05:08:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2D518001E; Thu, 22 Aug 2024 05:08:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CF0A8001F; Thu, 22 Aug 2024 05:08:37 -0400 (EDT) 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 6D2D98001E for ; Thu, 22 Aug 2024 05:08:37 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 76F581A0524 for ; Thu, 22 Aug 2024 09:08:36 +0000 (UTC) X-FDA: 82479305832.27.93C3175 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf07.hostedemail.com (Postfix) with ESMTP id 393614000A for ; Thu, 22 Aug 2024 09:08:33 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZXikz4PB; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.50 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=1724317634; 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=elPQ+tLq/JngyC9O8ZSXHOeYpkmReJmczepO/zPwyZU=; b=BUzO248lR5GUt4xQqW4pT7lDltlRrdN1mQTvoWTTfNxG2WtBK3N1yEo/RNsqfw+tNFX3pt 24GX8mAOgVLMD9ELmfngocV2wUNYGfBy5YjyPqbPhU13R3MaC1wZU2VyVTgq+NFwcMImJo Qu2+5MSwwePOgTy9+bBM6Eez+CZrsZ4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724317634; a=rsa-sha256; cv=none; b=18VXSjdEQSrDDNdv4vShyBIrIBYUa1pqYe6Gi7QymfWes+/022Zxn6mP67ohb1Upy7oHnf eEiTC6htwdh6DUXI7dSXxWhddlTTUeiJI6PWsGm5CA2UifWz/+Ww0dElRU3oovPyhUYDCy 18RY+j3eKJ6QgmCdCecL6o0dFvh4FZY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZXikz4PB; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5bb85e90ad5so631129a12.3 for ; Thu, 22 Aug 2024 02:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724317712; x=1724922512; 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=elPQ+tLq/JngyC9O8ZSXHOeYpkmReJmczepO/zPwyZU=; b=ZXikz4PBFACYJF1v0HPOvliOY/mqsnMF2gEybXsCTXyN0QUttycYItU1CczgfG+1zs HB5AdfEBZLY52Trl0gGPQLrmw3WonvQTNR+wQF4oDZiGOlu6H47Aoekf8gVZyWnz++GV 6CUBQ9sUKhwUMyaK9sy/cjoqFv1Jb4448sXAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724317712; x=1724922512; 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=elPQ+tLq/JngyC9O8ZSXHOeYpkmReJmczepO/zPwyZU=; b=D0TQe33mhWhHetsnmYTDNeF3TVkqgEhyY8lrC869NQvO6qMaTTSako5f8/KnvOP/9p wpWk93niLREG+ik1em7v5nUF4q5NMVzbx6gYq0XgNVPeoV3pyC9lJcFEbjjRxNkkpPeF W2p68Ubv3NOspBud9wBFZpMFiziGOH+7V7CAFwcGT2HiYqG4GjPuQpgWIVCKOOqhhT88 6ie8nRB7pKbTv4uP2/pJBEqvfqdCCBf59aLMlsgZ4U2mfqXc0C9E2TfEslCxzgYzveRq sZ1S7yS0fLQSIpOj73x0v7mfm+w5BVMSYH5lkvTnB6VqRJ+BJ19wXazTeS9bGg6ZiZ6X fDYw== X-Forwarded-Encrypted: i=1; AJvYcCVclEnhFy7dxz0zHQHlLmBHmf8Sn9+W5EHfmJOiYdhfLKbmKR/kU1wSshLAjqm9UIBG71JvD3gwrg==@kvack.org X-Gm-Message-State: AOJu0YwPMYsyd/xxgItK5VpAL/HyHPB4kctQRchvrfqHODTmW/Km7qDo lqakvb/EVYFWwY/42Au8QkQvbzW7yiecudjQ+cyUaS/DfdezZyQYoRLE3VYPFFw4PQX3H+nvrTs IfPGuWw== X-Google-Smtp-Source: AGHT+IFdk4aCNF8TBrZy8yuNMYb5jH3UX8eMpVxc8qHK99Pn3Xp7o+tz2Xfxa0PZeoACU03iW1g9VQ== X-Received: by 2002:a05:6402:3512:b0:5be:ef05:87d with SMTP id 4fb4d7f45d1cf-5c079292fabmr773026a12.24.1724317712164; Thu, 22 Aug 2024 02:08:32 -0700 (PDT) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a4c6ce9sm655914a12.72.2024.08.22.02.08.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Aug 2024 02:08:31 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5bed72ff443so824433a12.1 for ; Thu, 22 Aug 2024 02:08:31 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUrrsGF0aKGATq7bCuPfDVyxFLqEr0dhPdeLZcizI14cKUi7atqcwedeNbAyT6q1nv/JEOuP7K5nQ==@kvack.org X-Received: by 2002:a05:6402:2686:b0:5bf:a2c:4f35 with SMTP id 4fb4d7f45d1cf-5c0791ebfa8mr674463a12.10.1724317711442; Thu, 22 Aug 2024 02:08:31 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 22 Aug 2024 17:08:15 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: David Hildenbrand Cc: Michal Hocko , 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-Rspamd-Queue-Id: 393614000A X-Stat-Signature: 59p3sb8crx7uarywxm98o7py9yxy7g7a X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724317713-689597 X-HE-Meta: U2FsdGVkX1+C4B6izOe5+NBrCcC3S5Sjp5OIHcDRAcfZoYCSVjt2AaKTSaRpigMA3i/E/X4a2cZwwZs1yJ3V8NRbpc8JD8IsD3yAxZHM+XJuBgXygqus/hjXOh0ewPLtSp/X2sBSfQPB7UZKnbisBf/FNan9hE2qQRgKV4XKB5alwbjS+MAcUdtmshNGQmDeH9M5bxtKbnthxlAxZ4Nu77dv8pX8kl/Q6QosRC7icrrEsGt+QD6OCqf4bYpZlpRrVAgAe/az/juJ9hUrvxg+OlUx5lv1LxKNb1zO0ZhjILq37H6zw7QlkYFx581C05Va2lXyFMdqyj3BAdEtSur0o3C94IJy/W0PdiVDe2nvih6b0TvpaaOTJarAcgVRTtmATL2b+h13LZxKV0WqtLD3Y89CdYns/tw+tSa5aXUkVR1QbsCQ88bW+4+f9np/jllUDbsw6MCdVUuoFJAMEcc2lZmkJCR5zCT4yHcVTPCAIwUJd2rz1ZfViFMzjMelkpaCrd6BU7uttxTRONFIwoP+CRUcbk65faRqVx+CwaP3SRkVctD5z6fVB1e1OgRW5ca1R/OrfAqQmChoR/NWmD3LGg7+f94fgAJoNsZzRatJfxATD7xB5Ol45BcwM/8dy5UD5BKEmlAbe3TbyalL4HBu09stdBOIKM3J0R3uDLhCKvq2jyVuH2GBFEU7y1r4CyLrPktm2UaOEyvJD19nFaiX4fi8h9GQm6z0hkU3AMK+0Em8rR21cmYBdBlEnc9oSBIq1dtvOAcbfEbF9vrdc16CjVDMcd8H6bFh+Rcd/KfDqZUmLdMjZ/+bOmyx80goRrS86d6ixkSFoU+u8jZ2pylVImMX6hm1Jlegj+HUp6EmgogOzyit4OlBeCndicfSbnMtJsfAulPtNqofeHkacoRReMDVboEq1NhnUJpC0lEy7Pr0Yntn50YJXzbUgSu/ISAWEVS+EyTqyvR0NScCG18 gMRSwExe i5ab2XYMnfRx/6cv/e4dg5rCWegxijGSgVbTzPtPcn7LPytNSZSUnrAJzPYdSjoGiCjKgcXJWWPUkfgLSzY5m8iTC2vZJHRCY4CDS0OaVARm65NhbFob3pkEZg0SdIfaCvXDs6siri978KnTl2gtWyzzfoCt9RsTXRaPsinXd2JXg5kWC4z7uSgrZuXq33rViQrxBoQ0ARnb8CtsAKiWyuduKXPMRxo4XyXd1am7PSzPPiw5J6U+X+wkmKnJTRiPlm7hhjMc7fiSoWhk0zx8tQw/7SILN2Q7u3bkoyP1vxGK+46xdqWIlNq2ftM7OMRlZ/hp8XARYuTDaw+dvVLY0m6Nsabd38V1EUV9kEFcXThSEuuJaXrgdXZV9aTA0Y11Lvn2TJHEV+VaWc3yeQYkzjf1sb30EYa8BoQzbex/MW460vmaRCL0yTrjevtuLDHYKymTpNCzyDOP9HmshzLsVETOyTzzG2z55Np2BShSmZZYrc710t/kgtoctxgdsoht+ZaO5pSpu+nBHuQEb/kvnqOu31KjrUwuEQZasB8qK/yofxzML4l2EMltD/wachF4iU85UQ/PABjGIFcw= 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: List-Subscribe: List-Unsubscribe: On Thu, 22 Aug 2024 at 16:39, David Hildenbrand wrote: > > Linus has a point that "retry forever" can also be nasty. I think the > important part here is, though, that we report sufficient information > (stacktrace), such that the problem can be debugged reasonably well, and > not just having a locked-up system. Unless I missed some case, I *think* most NOFAIL cases are actually fairly small. In fact, I suspect many of them are so small that we already effectively give that guarantee: > But then again, sizeof(struct resource) is probably so small that it > likely would never fail. Iirc, we had the policy of never failing unrestricted kernel allocations that are smaller than a page (where "unrestricted" means that it's a regular GFP_KERNEL, not some NOFS or similar allocation). In fact, I think we practically speaking still do. We really *really* tend to try very hard to retry small allocations. That was one of the things that GFP_USER does - it's identical to GFP_KERNEL, but it basically tells the MM that it should not try so hard because an allocation failure was fine. (I say "was", because the semantics have changed over time. Originally, GFP_KERNEL had the "GFP_HIGH" bit set that said "access emergency pools for this allocation", and GFP_USER did not have that bit set. Now the only difference seems to be GFP_HARDWALL, so a user allocation the cgroup limits are hard limits etc. I think there's been other versions of this kind of logic over the years as people try to make it all work out well in practice). In fact, kernel allocations try so hard that we have those "opposite flags" of ___GFP_NORETRY and ___GFP_RETRY_MAYFAIL because we often try *TOO* hard, and reasonably many code-paths have that whole "let's optimistically ask for a big allocation, but not try very hard and not warn if it fails, because we can fall back on a smaller one". So it's _really_ hard to fail a small GFP_KERNEL allocation. It used to be practically impossible, and in fact I think GFP_NOFAIL was originally added long ago when the MM code was going through big upheavals and one of the things that was mucked around with was the whole "how hard to retry". Linus