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 25493E77197 for ; Mon, 6 Jan 2025 03:04:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 100966B0082; Sun, 5 Jan 2025 22:04:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B15C6B0088; Sun, 5 Jan 2025 22:04:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBBC76B0089; Sun, 5 Jan 2025 22:04:17 -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 CE33E6B0082 for ; Sun, 5 Jan 2025 22:04:17 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 55803A12DA for ; Mon, 6 Jan 2025 03:04:17 +0000 (UTC) X-FDA: 82975533354.01.59647B7 Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf08.hostedemail.com (Postfix) with ESMTP id 8AFAC160012 for ; Mon, 6 Jan 2025 03:04:15 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e4SVDhW3; spf=pass (imf08.hostedemail.com: domain of guoweikang.kernel@gmail.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=guoweikang.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736132655; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=W0jk0+Fx1TyF2nwJW2NLfCmuunqP1uYM3Pt4+W5cPKw=; b=5za9bTiwxkFltVTY79DuHUM683EOIUsHLocdEPCEnG6VVUm2Q9ibdZQdDwBTJ7Qfl+fWdu OMHAQqTJFVNQQ15cyPc6b9Pw3+PbHJ7NtbIeitelAAX0S0Yn2QHTHFVzMOWaW3zj+zSkX9 4cS+EQ2qNqRcDWbyJd3G5XhFgqiKcg0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e4SVDhW3; spf=pass (imf08.hostedemail.com: domain of guoweikang.kernel@gmail.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=guoweikang.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736132655; a=rsa-sha256; cv=none; b=CqhPYYyMmVWPvMUP0cpBv0kbQ0BNaCQTvYbXYfnHsu1lmSqaZekXncLGAUBi39jEhLhn5n uPgeaoVqaaW5DEO2U/Aif5toyvx46udGoKtxa8y4WCYA7EgovpkRJYXd6RdCp3SuDICGRq IiAVpAWC1fwhuVvU/2iNIcVkHhgdHnY= Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e46c6547266so17283738276.3 for ; Sun, 05 Jan 2025 19:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736132654; x=1736737454; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=W0jk0+Fx1TyF2nwJW2NLfCmuunqP1uYM3Pt4+W5cPKw=; b=e4SVDhW3r2MMRCq8Ul1S6WM0FkaMIV8XTMCmcBI5guvrzDjgCSUAY4DeMaamjg6V0L KAnQMs0AlldJh3PAz1K7ZjOJ+ymbyVc/l0ZqHhoNtENPSpc9qQCa+FbSbt0g4D7vstWS Px9/6b7F0FzFwoI6TxjYoXbh/SvXRW70J3aQBElfMbHnlYRKAGX/6BWfywty5NkJQJZ/ KKBxyG31L6sVezW/cKCy0yqPB5b7090C/TArYQ1QLVzd9Qari2laccai/d88/oenpy70 pSa5QywJJ6bp6UAioQR+ZsOABohIc4apWJM6GgcAHR2QPcfItBR5tcFlTSVVTRBBrpyP A+gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736132654; x=1736737454; h=content-transfer-encoding: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=W0jk0+Fx1TyF2nwJW2NLfCmuunqP1uYM3Pt4+W5cPKw=; b=nhQmiDJ0Ir3uR6w5YtHFiP2VW/indjOpK0rmaPD9gqsR0EfMRoZRQCbCgIfxYjgi9n I8I0Vgv9MYmdUcmopgcFCciUmSDsLNZJZJajEviyEJnn4NFOyY+6mIx/fB2EOv1kVwQj vuJ1igQABJ/A+YsijaGql6xO4rTdWCsRueZ+y7Sl12sIrav3WOgG/3wir97AzMp6b+SZ 3P0yfaeRk7h6HurYR+g6WvqzMwXUCUf6t/4hZRy+GyepR+n5xuDWCZauQVy13bfQInri gZ3OeK2ch+VDcyUmZLAWAGMUxKwVfdZtIlQIHw6lZHRPMYS01Woybbwos1Y7I43qRESC IAnQ== X-Forwarded-Encrypted: i=1; AJvYcCWd0wyXd1iAPvT+gEEZSEf09oyO6ENCkEgfs7Ti1m16Htpc4sHkjcRRh30J9qbelNB+QGfDTsFDMg==@kvack.org X-Gm-Message-State: AOJu0Yw1Ad6aH9SHLn042jA06OWN4qhM/tMm8gy6h7eYrhA8ep1KAWUs 8koHEkKahS0l42xsvLNUek9b3HgNfsJOGdrtIozCNarEjyb+C49oNbeFQOfpsMwMXiZSJTbKJ6J 4mGKE/eqIExToDgZ1MGguspcqCrw= X-Gm-Gg: ASbGncvJN8qa0Nnxc7btNItCKNzwVpjPve4HNA0ljjIznAOi29D6jtBUBMxccjlvxk0 cjzkvWPqfgjFf6l3U2w+9F2v1DdLARsKk43hNtns= X-Google-Smtp-Source: AGHT+IH8WO9zK+IvzA/2siCj0ZWQHd0NbnK7lXJWixkSxK5jrbbc7nu/zaBMdGcrkMXyaOhKYxu4oOvtTzI7Iimx2Ng= X-Received: by 2002:a05:690c:4988:b0:6ef:a5bf:510b with SMTP id 00721157ae682-6f3f80e5251mr420334177b3.1.1736132654625; Sun, 05 Jan 2025 19:04:14 -0800 (PST) MIME-Version: 1.0 References: <20250103105158.1350689-1-guoweikang.kernel@gmail.com> <39e6c57c-0a8f-4f4a-b6ae-27f2ef6bb8fa@csgroup.eu> In-Reply-To: From: Weikang Guo Date: Mon, 6 Jan 2025 11:03:38 +0800 Message-ID: Subject: Re: [PATCH 1/3] mm/memblock: Modify the default failure behavior of memblock_alloc to panic To: Christophe Leroy , Andrew Morton Cc: Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8AFAC160012 X-Stat-Signature: 6jta8nyz3mnmeyj9syikjf65d5gi3gih X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736132655-482848 X-HE-Meta: U2FsdGVkX188zDqIWVclmJ6cK0XUdABqFC6zQGFQ7rviFNzMg5kMQSCBsehgwEhWOFyEO3mz12eiMcIxFr03mofdwfJT+EtZVU72Crjvl/Q6wIlB6Dzl5n09XlGUQ0TTi3hRNu05yQ16NDAMOvov8KRI/gXwcjfTira4xv0r+tj8LsVfOZUELK8ObAyGAtH9U0bWQqD2IalVAwwCrKNdd5zcbBCJcTqly0lf6/7LwaHkURbsTvhRWdXNaDOcf+uwXsAQT5I60Gk4wxmAYL6vLcNdfPWbV7kl03+EDiVhgeWy4Ii9zeQbmjbk2oC+c1gPQpzE8Ifv5DxcM20L6KhKudG52ObBik5hah5U6j0ExBYaY9QZM2ehHHQY552ZTzfVLrwg5WbhyTSig9hn8x8hqkU1Mk/dUL0iDFy8uz2x05LQKKiZjIb5Nx/uNrdm0mCea3UoM9Rp0xCSUQGInpfeflq0G48S6lHlea33Uh9Ky1E0j2DM3g4YYwpJytmo6C86SAlBYtaCMjq3aBhw0NausQ075q5Y5N/9+pMm0EuyPZjhhwfr/WloRASoaS3MwVKsdat6poyZexTC7BMtiJULasn67TipfZ1zz8FEcBpiQOVh5C4vJ8L8A+XdoVgq7ktf3r5s+C5kBPeq65H7S9xKv5w1j6oiaO6Uv0qdCcJFCO1UX/cjj8gyH8SGsi7mbXSd4MFGxZ+FPFuRZ4KPniZn0acMbHbimATdy2qkeNPhRlUIbvRboVjmi+GcUfEzmnolwO10bluCcudqJ7+sgx/OBQBfIBXqUSa4rxE+KTJNfXtlMeQtjpv5iwEpwgBmIG2ao46zLBG1ZfdZcFuW5tKZ6kA4dj779ZHiobLvMF6QrY/vByJIi7V0z/V/7PSw6fWSJQCETxLE7CFNGRRZ/GI+5wqmT8KKUcZKJnC4GxYUlPaWI+hfqW2YGiNlOJ6cmt3q4NKXvxhZDjhiTwV8bl0 ywztET7C pf7Z6EKDARL1PobBPzaNxenAWEKCNx6GuHICfAtTwa6gz0UJRISQ/oyQtqQIL5B6AqYHq8H61PRtyg9FVcmPP/b9QUhqYbw7t7yAztf55Q/fySoV2mJOQVXsaawaLq5q37k7EGsKuErRwYC/Ux3bw/kXF+GEaAmCKPJasvoMYUmcVJW5KrdkydhUUbJdyzybw6wr52lU1r8LDH1a2IcFqzrUCrwY950rcsjpdQKy+Q22sx8w0JR8HPyjqCzFeAjwCbmn0QZ7EJszOwXNXCMuwDHAqlsvTmFymOyaLnPTyxJElOravRuzS1jwgEFU/hqxxnqqsM7XRPJHkZ+d9BYldUpif1d5ijEedBjVt+muZEi1Do9j2WU+8oQzqnqY79Z0XnvB/64E/DJx+wejRWjF1Sd6EssktSd9kQTWhVj1WhK4XemGqEbMI78YeWwBE9yyQPs12ifB5GDnziPGZ2qvx+7QGvP44EN9y8xSPgpuD5sqrKQHV7oUcxQ04sBcL9CzlZTzr+qynkFvhBc+uE7Ne39nf+p23RflYzHoD0+W/sS/Ro8Q= 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: Hi,Christophe, Andrew Weikang Guo =E4=BA=8E2025=E5=B9=B41=E6=9C=886= =E6=97=A5=E5=91=A8=E4=B8=80 10:17=E5=86=99=E9=81=93=EF=BC=9A > > Hi,Christophe > > Christophe Leroy wrote on Saturday, 4 > January 2025 03:58: > > > > > > > > Le 03/01/2025 =C3=A0 11:51, Guo Weikang a =C3=A9crit : > > > After analyzing the usage of memblock_alloc, it was found that approx= imately > > > 4/5 (120/155) of the calls expect a panic behavior on allocation fail= ure. > > > To reflect this common usage pattern, the default failure behavior of > > > memblock_alloc is now modified to trigger a panic when allocation fai= ls. > > > > > > Additionally, a new interface, memblock_alloc_no_panic, has been intr= oduced > > > to handle cases where panic behavior is not desired. > > > > Isn't that going in the opposite direction ? > > > > 5 years ago we did the exact reverse, see commit c0dbe825a9f1 > > ("memblock: memblock_alloc_try_nid: don't panic") Thank you for providing the historical context. I did notice the existence of a nopanic version before. In my earlier patch, I introduced memblock_alloc_or_panic, which offers a more explicit interface to clearly indicate to callers that they don't need to handle panic separately. Andrew pointed out that in most scenarios, panic is the expected behavior, while no_panic represents an exceptional case. This feedback led to the current patch, aiming to adjust the default behavior and open it up for discussion within the community. However, after reviewing Mike's previous changes, I now believe that further adjustment to the default behavior might not be necessary, as it could lead to confusion for many users. In fact, the interface that is widely used externally is memblock_alloc(), and I think providing memblock_alloc_or_panic explicitly might already be sufficient. - memblock_alloc_or_panic: https://lore.kernel.org/lkml/20250102150835.776fe72f565cc3232d83e6a7@linux-= foundation.org/ - Drop memblock_alloc_nopanic=EF=BC=9A https://lore.kernel.org/lkml/1548057848-15136-1-git-send-email-rppt@linux.i= bm.com/ > > > > Christophe > > > > >