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 5798BC3DA4A for ; Thu, 22 Aug 2024 06:40:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA91894000B; Thu, 22 Aug 2024 02:40:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E57156B02AE; Thu, 22 Aug 2024 02:40:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D201B94000B; Thu, 22 Aug 2024 02:40:26 -0400 (EDT) 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 B2FF56B02AD for ; Thu, 22 Aug 2024 02:40:26 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6483E804D1 for ; Thu, 22 Aug 2024 06:40:26 +0000 (UTC) X-FDA: 82478932452.08.DE725DD Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf02.hostedemail.com (Postfix) with ESMTP id 15A8880011 for ; Thu, 22 Aug 2024 06:40:23 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="IvKX9H/F"; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.47 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=1724308743; 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=FV+CxgS7SBQNoCHIorUngjr+oE9e9INqSoC4Nwb3mnM=; b=lfqQV2gHrzO2p8iqFQYbfDU90se1I47m8DidJx+wKmtsFw4B71W/WuRnHmtrqPEkns4kII Q0eLXaO7TmmGmxP3MImdqg251pVjdRAXEEWkB138qvZ0/i2vTIw+1yLtGP8onWqWLcuPPh nU1G0ylIKNRetwq8GUPWnGnLKFedTZI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724308743; a=rsa-sha256; cv=none; b=8ZWt1BUOGql3stYrcSYPZGoKjN4FNQ0UgXuLnPgdra276AHOYTua2quoSeZ6Hz69Bw58Dl SSqKgZkIphAXhXRCPHkQ2RZQiiZmxJ/vdygyBOZb+OpdScamvW2ooQlNwELR+8p39sMZsp Xr0cQYmCTON/CqlhhC32Y57cXvFVATw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="IvKX9H/F"; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-52efc60a6e6so510051e87.1 for ; Wed, 21 Aug 2024 23:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724308822; x=1724913622; 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=FV+CxgS7SBQNoCHIorUngjr+oE9e9INqSoC4Nwb3mnM=; b=IvKX9H/FT9yLfEV/sH8aGaXDXMojYTqCWDHLe/eNcxX8250mZQ8lRRQ7d3OKpsGC0V nAKF0UIujQj3fg+6TG5tP/A8gglDHrFF/Gj9re2ZqNGtLYkJMXPFjcA+EMIud9Nd80b2 ixg210Vy1yAg4Ior+NUokpA3AJZrCbbvIPekY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724308822; x=1724913622; 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=FV+CxgS7SBQNoCHIorUngjr+oE9e9INqSoC4Nwb3mnM=; b=A2RfjayH2qbb00B0EviQgBAhL7SUtwVB+0ywB1b72Bta1SJ3WHQY9nkuNfh0VKm+Uz KB7/wqVjFKN3WldoMMuDXUKPwQyyYcSQhYm9P0cA5YTx6k/VOGzDFQML/nZrZABIfQ/8 scde7udAAn9XNcZvQc8IyImX4+nbIev0p1nhu/3UEmNqjJpPTER47Wzd5gJ4MnFvkw8t y4mfvlUBnRfLPwiTK/AJ6PVe28Rg5Bf+4/5I7TEm6ltSGCLiRgZXr+H1H1l45osred7y /GgQbdCXx0Ccg15lwXN6z9mHr4ZWHo60fwiwYfOjuXSnOCxhPIQrSkTKPCT0cU7uOkbz bibw== X-Forwarded-Encrypted: i=1; AJvYcCXS4tI2GwBDVsuhkEjZSOqzZVxfKHwrDWB6C2HgcP24Moo8HEtlwDqWnTYnCkpRBVeR4+sjk1g7Gg==@kvack.org X-Gm-Message-State: AOJu0YyhrLI7bowHMLRJvliGbs2phXoc+z7c2jYZfFPEecX+xoBjZH0t 7G+wgVF5UjJKKsxXtqjl6JxbRY7PV5x4GyLqJL56y6nq5Uj1DVnCIOje9zD6hsHy803mDQ7mcxv rqZgCeg== X-Google-Smtp-Source: AGHT+IHsniWShNp4ZnCQT8dT8oZGAaVLWZLkwKQumYxTPaZKBESSggxNrkuhmdO93VnX7cA5I5P0Sw== X-Received: by 2002:a05:6512:3daa:b0:52d:6663:5cbe with SMTP id 2adb3069b0e04-5334fae8615mr413649e87.12.1724308821942; Wed, 21 Aug 2024 23:40:21 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5334ea36743sm130504e87.78.2024.08.21.23.40.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Aug 2024 23:40:21 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2f3f0a31ab2so4529731fa.0 for ; Wed, 21 Aug 2024 23:40:21 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCV43bjRxRNDeQtzx2C6wVpvybUKtPdWQavxUAxG4vClImGkchkyBd3IyUPZkcsg3qvcBwmK8ePvEA==@kvack.org X-Received: by 2002:a2e:9b14:0:b0:2f3:e42a:afc2 with SMTP id 38308e7fff4ca-2f405f2517amr3488751fa.49.1724308820768; Wed, 21 Aug 2024 23:40:20 -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 14:40:03 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Michal Hocko Cc: Yafang Shao , David Hildenbrand , Barry Song <21cnbao@gmail.com>, 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: 86mh3g67bgn6upz91bcjkzftj3edoabb X-Rspamd-Queue-Id: 15A8880011 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724308823-584321 X-HE-Meta: U2FsdGVkX1/d7A1Xg/hvk0yZf8zo6++r5tOuGoKYRTK+dAoHXWARfhIpIj3sgmhaPuSeb5echuWwNq6jUm+d1DiG5T/atqlENuiIYAARBd0jaUXxBWeGLXZMQxBlVirW/x5r5MJeT6dFATjKpnnKHyvlS7SYKpCVUlpWIaJVUgZ9Wl6ZjhWFIL8igwPejzp871PUZ4RVSWWWjt5iGZQi0bRGTePHc+N7UjnP7RtciQwxxItq4XsAJqoPH1mnsYXdyleBqS4IYfXXphCy2x530l2A+Swht9tepffrK6x7CJnnvUzb5ZbnKaEQsXRe02DBroSkaYKat3BZUQR3EH35WUddNu9yCIo98GjsWiJgP6k4V7DJxJk7hXx2lUGHiw9GPUN0aHv3imb+BHvHbppvdhnVfnLev+ePWEY1nYh4KBlk3IkBf9l19aXF/OHGlTMHSnNskG/Se2CXPYahL2IXzhY0RqlVxptUJ13xnhM2SgOyYxfW6yLXJLMA3qMDLNp9DR/vA+koYUWcaoxiU53IPI2Glg0AZHMSTTYnafcnSuBy5mQijphTLe16vuY4AQooKjSCzAVwbvkxHH9Eb2OpcYsR7r93wny5JOHcajxxeE6gt3PFihKJJZOHv40SrrhMMgVTtx8dWuTqQ9ej290GNdT+1BWHSwoGO7k5vz0rR7G45yPjFKK68kb1fpGQR6v7qyzY77Yv4ow7DcuWULbwQiXuxyuJ5OjwBm59Ihv3I5e1b87O9/pwJS41i0oVdLXO9YCDUXY4s5Uaznw6z1Wayf522Xj7I8a/OFWy/oaadTfx3PRH1ZKFjqISVuNciYn5RDDC+54WmNgMVhuv8NaXIj5W3oq0RBiA7sQg9CbjK1Ry+mNjz21v4c+vZvGzGCpKtxFWWGELk0lrs+jzQwG5Ab3hUUkspwAZ+6dY75Ip/uF8kHjbQoiaWIDIhPsKeEWVUht9VJR1t648p4YPicF cJEj6XH+ Y6oYiWzhdtzgW0qdUyK01ufOUhQCkVBAZJ+O9aVIqUjj4CESPchruFm0bBJoC0ZpcpoxtW/1Ar0eu52dxqXYk9sF9OdlG3EmOzlGGYctsyUmukKWyA9tgBxRKJaqvQ/aoveu68pJlEGkSw1XV5oMY88KU3NFzrwi7h61PldvUcGboBeKk4STQlqHU2AJcyCkOoZAsGxe15U8PP3oaXCU3oxBkUwN8s4v1AYW/3YLSUMDEpfD103Vv4hagN5F5CRuDjDY7b4P2UaYuqj890Kpdfe4BUa5Qd7NZpeGhNomlbyjQf/QHh7aDPcGfHHPXG28C46KrL9sl6HKvfepJU3agLWZx8ZEYaX2xNVgVICky70IEcyd3iXOKAjKEsK8/rFGinPgWdgYkBn46UqFTKmyaaPLAtt7AgWYb7STi7azHXlm06Mne5rBRmCkwkR+jg6RJmMfHXLiujRp902iqgQU/BGIsSVdlipGOHQtjrGyVPigquNmQCPnut6/MzSaHCydzplu7bd03TCPIMQv9dnavJ/qmM/AOqIrQwEMeUqpkmUj9rnfZCF6PeYMkCp7WmieBm0Ixl7EeW7/PYDRfT7p9zPG+Wg85FKnQ9unTD0wUv+c6zsY= 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 14:21, Michal Hocko wrote: > > The reality disagrees because there is a real demand for real GFP_NOFAIL > semantic. By that I do not mean arbitrary requests and sure GFP_NOFAIL > for higher orders is really hard to achieve but kvmalloc GFP_NOFAIL for > anything larger than PAGE_SIZE is doable without a considerable burden > on the MM end. Doable? Sure. Sensible? Not clear. I do not find a single case of that in the kernel. I did find three cases of kvcalloc(NOFAIL) in the nouveau driver and one in erofs. It's not clear that any of them make much sense (or that the erofs one is actually a large allocation). And there's some disgusting noise in hmm_test.c. Irrelevant. Now, this was all from a pure mindless grep, and it didn't take any context into account, so if somebody is building up the gfp flags and not using them directly, that grep has failed. But when you say "reality disagrees", I think you need to point at said reality. Because the *real* reality is that large allocations HAVE ALWAYS FAILED. In fact, with flags like GFP_ATOMIC etc, it will fail very aggressively. Christ, that's what started this whole thread and discussion in the first place. So I think *that* is the reality you need to face: GFP_NOFAIL has never ever been a hard guarantee to begin with, and expecting it to be that is a sign of insanity. It's fundamentally an impossible operation. It really is a "Daddy, daddy, I want a pony" flag. Linus