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 800A7C5320E for ; Thu, 22 Aug 2024 09:44:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1911F6B0309; Thu, 22 Aug 2024 05:44:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 141686B030A; Thu, 22 Aug 2024 05:44:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F23966B030B; Thu, 22 Aug 2024 05:44:45 -0400 (EDT) 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 CCCAD6B0309 for ; Thu, 22 Aug 2024 05:44:45 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7E146A1537 for ; Thu, 22 Aug 2024 09:44:45 +0000 (UTC) X-FDA: 82479396930.25.E9550FE Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf24.hostedemail.com (Postfix) with ESMTP id 688E418001B for ; Thu, 22 Aug 2024 09:44:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WX5tSRo2; spf=pass (imf24.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724319842; a=rsa-sha256; cv=none; b=CUINfwz+aBmGqGKb2XCfcTarWBT6f8u77H0bmjhH3SAxf7aaB/DOhk4T3qilSu1ff/0qgG oqgNrdPbWbauXqqUSAI56aAqPE9cxMLHgCFYwEGOo9+0imySsWI09GnEAzbDPMrnJpm743 xhDtzpfeIsufdyocJj+YHgLSeCHRtfg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WX5tSRo2; spf=pass (imf24.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 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=1724319842; 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=uWXamfb9PmO8IqynHQ6je4u3jkpRRtgsSbtDZ+0taSc=; b=DTx5u+P/9cXcxN7v2t6eYtUsE5heBsev9n9LP94n00zn+pYN5JU7yOxCApaGJCj7o9QK4i sWeMhkdOGOut1s8mKbPwv8fbbapkCo6Ifmzt789514J3TZsQa5hKcLb/XnmYP6SixNb0VB 4kFdIyyzZG4wmG6Yjcrqld5rqBlK1s4= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5bec7ee6f44so919019a12.0 for ; Thu, 22 Aug 2024 02:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724319882; x=1724924682; 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=uWXamfb9PmO8IqynHQ6je4u3jkpRRtgsSbtDZ+0taSc=; b=WX5tSRo2MSTatfmreLXuVBr49ZME+N80p2ao1TMvTt9kGN3hRXkQe9rR4q7CqeVAN6 nr0tRp6Jjz9Y6ivb84BY/Dw+z5t/MZ7ic8ZlD5P69rKN5AwrWQzebhYWyfAUwLMGjQkl /zYu2RaPy/hgxHJvBeq+2W7L168JADduV0HtU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724319882; x=1724924682; 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=uWXamfb9PmO8IqynHQ6je4u3jkpRRtgsSbtDZ+0taSc=; b=Q1lL5mfyCF//2NjejVZmBqTGzrBY8Vbo/vi2hP1IPTo0K5LuFrmtQZOWCzFaQ101KM 2Uu7UH2nUnnhS08dsUce/w0yIGWEgyll5CyML4xAGCiPXolPnYQIaXdQyVZB5P42MPI6 97BqgYE22Z8q3kWzHp4aJDmyQx/myb8jt9kNQqg+ymMTvG3laKahbR2O9mKqRLOtX6kE Xab51EP3ThSU+wLKwke0t6WHzSH1+eMcHpVIFmdRoXRKDaVtBzmmFs+4uyj0u5XHZjjw 2K5ZY8VPlccZM6fgE+y04vFulpiv0IN604Qwcir06wEY43bSNZk4uRH4QLi+ZjIukXi0 +9zg== X-Forwarded-Encrypted: i=1; AJvYcCVkVxn7sAJjGPGqRQHXxHUWjqcKAugcO0+npB/fgtRJrvy51Azki0A5w2zW3T7bP9uq8y19HaLeiA==@kvack.org X-Gm-Message-State: AOJu0Ywgya11P9zODcsvWmWsSmi1LQQ/EJEPMXxqNo8lG3R2U9nXRsYm 4BMT6coYu6zJ4XAJlRC3oLZxL7/KaFCZuJAjdpr9bE9IrGJiehY5DpER4I7yn1k5II0J3FvMERU TeDb+Ew== X-Google-Smtp-Source: AGHT+IEZM7kgeM0w3zQdCDKbmQBsUMByEAC7BILyLeoC1aXx1nBdMtTqBx+vGvk5A2j+jfxLTp7gDA== X-Received: by 2002:a05:6402:35ca:b0:57c:9d54:67db with SMTP id 4fb4d7f45d1cf-5bf1f0d1b75mr3589705a12.9.1724319881484; Thu, 22 Aug 2024 02:44:41 -0700 (PDT) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com. [209.85.208.47]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a3eaa90sm691457a12.45.2024.08.22.02.44.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Aug 2024 02:44:40 -0700 (PDT) Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5becc379f3fso892601a12.3 for ; Thu, 22 Aug 2024 02:44:40 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVB1BRveU1MKzLElwJdgOsEtWE4j2QyDjxUSKhWb20KLWtsbX8i0z/cfgPbRtsyFZMqhjRVLXZjsg==@kvack.org X-Received: by 2002:a05:6402:5243:b0:5a1:83c4:c5a8 with SMTP id 4fb4d7f45d1cf-5bf1f0d5b41mr2904696a12.14.1724319879729; Thu, 22 Aug 2024 02:44:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Thu, 22 Aug 2024 17:44:22 +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: 7kxmo11ur7gqm9sknkg5m8trxctmithf X-Rspamd-Queue-Id: 688E418001B X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724319883-864928 X-HE-Meta: U2FsdGVkX1+t/DwwefgPo0y7/TzrPAfq0EXtVyzTw22lj/ph33U6ilugWcE8uoOeoU3ZL5s1f7R7nkUeQeggJzTYSF9ebmsLprNvLNmScwEZGbKlT24iXtYpq2nzcrM6aEKCFp1MsXKCf7ZeRNZDiixyQ+5y6byRVAPbBiXVzl8L37PfN/4T56Z0a6ntVsBRJBUUU7hASvQxQRX0U/wjZ191rdzjx5knVVzyBS7dRDsiuF3dAOWskByCd6Km7HIaxKVO9WOwPT6sTTWskn7vivUdOV4WObZyNQZ1eU3fFojjT3jeaio3CgmC+BiC6Ua2Wkc7xPA0vJtpvrIovppZmkanzaE50RF3qimkP5U0J4LETjzrTR6broNfRvjeVCoZ7/pqDqpjuhMT5lX85evO9NWqdniVGOBQef7MjIVcqY2FTZDtdbMiWugOJtGBOo8w9hoGstmWUdXB8P9WNEZT+1VF2Fybc7gWJAp6+dOklTjLye50ncFXQz3XUSGJ7S5YxLMNnW4V59fqJlW50102mtWZFcbpciNwJ2OPRLHCtMBZTISbzyUh4T+dFJHGrIYLje6qjGuzB9yFIqub/VYovN2z7PzYmlHJrBD5UpACAH/ViiA5IRixHXiHMH7/QnZs91FgVOpayv/q3wRH8e1E3yvnPFdL98JG1BQCSYdLpyG3eF81Kga6hfI/zoP4DdPDnx6YoQB0hc80iH6w/jNBFjQ7wkqr6ffq+xcwslLPH7wAMSEE+Dqb/KGl4+tf4mit3rNq+FS14XvcT9gxvyt+s/iifU8IyiGe92aSYx+lmB5AT99kIeSc8dRivQbMxq/SePLbr3rP77M/ERFIOQDJe+o57Zyu2HsASEjmP/oWrDafuoxouuc4hCaWUmHFXeDhXNiiQOvVkYRk9vWKzQnNLaEeE+fnzNLn6pbsnqlpN5S+28iKxtRJQ0SK0TN4l4xid9x8qlMam/2zePXLO4Q 1kumhkl7 kHC2/34ti7VHvhhi4uW+wuG2pX4PQjXJXvC/uAkjkabYcBOsKiM2E2gnJiHgDrh0IOte8/dwHd7euVQCtf59cTk/PB8wzwu0kBf5mvIUu49+oGcq48rhiI0jkAZntBF0y6GDpsXqA23VUxTxhsvSwNcYyyK8r2MkgegyAWWjme2K/eOeRQxA56BAwcTkanMF9fxWptN0G65Rn8OuVvZUa1wMwIcTj3wJnRee4ZLH+lpYoAdpOSaOGqttF1KaiMXprYXOx6JNVaEDKv95IK7Bdpec8/tK++BQWiYubKHpIuf3ZcEgZU3Qc9ylCrCOmi7vi+hTvBEn2xUa4T/Kiv4Mz+teNPvFvoZu8Hb94sXycrj9Rm6yzXZwvDlviZ5gFAurNj/e7BTiyyTO/Ud0xhi9h+4Huv0+ahYFJtyoowSQgIWOOhYgigRAHYR1RXF6+4dogACD3jAosDpyrx0guWU17z0DMhB8Zl4N6vDba5f4ltRkvgQdhHu0I0lIZOoOzQl64nJTc+g0JsrFZ7aR1UPkE4TbO6sAdummMY5P1T1ztJ8RnpznW2QrGc3D9xm5KGOfyTV7ZTLNvrpr7iJaY45z3oRLbp12K921z3ws472LkpnqElyg= 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 17:33, Michal Hocko wrote: > > Limiting NOFAIL semantic to SLUB and {kv}malloc allocators would make > some sense then as it could enforce reasonable use more easily I guess. If by "limit to SLUB" you mean "limit it to the kmalloc() cases that can be done using the standard *SMALL* buckets, then maybe. But even then it should probably be only if you don't ask for specific nodes or other limitations on the allocation. Because realize that "kmalloc()" and friends will fall back to other things like __kmalloc_large_node_noprof(), and HELL NO those should not honor NOFAIL. And dammit, those kvmalloc() sizes need to be limited too. A number like 24kB was mentioned. That sounds fine. Maybe even 64kB. But make it *SMALL*. And make it clear that it will return NULL if somebody misuses it. Linus