From: Weikang Guo <guoweikang.kernel@gmail.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mm/memblock: Modify the default failure behavior of memblock_alloc to panic
Date: Mon, 6 Jan 2025 11:03:38 +0800 [thread overview]
Message-ID: <CAOm6qnm4pN95kJK8bYfu7Z2Bp_6_Gn35v2WyMmYraQ+YMYQEdg@mail.gmail.com> (raw)
In-Reply-To: <CAOm6qnmboa3OrznkUC5BOj_EzEi-ifuVBUAhWeM+Y7Y+vM5ieA@mail.gmail.com>
Hi,Christophe, Andrew
Weikang Guo <guoweikang.kernel@gmail.com> 于2025年1月6日周一 10:17写道:
>
> Hi,Christophe
>
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote on Saturday, 4
> January 2025 03:58:
> >
> >
> >
> > Le 03/01/2025 à 11:51, Guo Weikang a écrit :
> > > After analyzing the usage of memblock_alloc, it was found that approximately
> > > 4/5 (120/155) of the calls expect a panic behavior on allocation failure.
> > > To reflect this common usage pattern, the default failure behavior of
> > > memblock_alloc is now modified to trigger a panic when allocation fails.
> > >
> > > Additionally, a new interface, memblock_alloc_no_panic, has been introduced
> > > 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:
https://lore.kernel.org/lkml/1548057848-15136-1-git-send-email-rppt@linux.ibm.com/
> >
> > Christophe
> >
> > >
next prev parent reply other threads:[~2025-01-06 3:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 10:51 Guo Weikang
2025-01-03 10:51 ` [PATCH 2/3] mm/memblock: Modify the default failure behavior of memblock_alloc_raw " Guo Weikang
2025-01-03 10:51 ` [PATCH 3/3] mm/memblock: Modify the default failure behavior of memblock_alloc_low(from) Guo Weikang
2025-01-04 8:38 ` kernel test robot
2025-01-03 19:58 ` [PATCH 1/3] mm/memblock: Modify the default failure behavior of memblock_alloc to panic Christophe Leroy
2025-01-06 2:17 ` Weikang Guo
2025-01-06 3:03 ` Weikang Guo [this message]
2025-01-10 10:17 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOm6qnm4pN95kJK8bYfu7Z2Bp_6_Gn35v2WyMmYraQ+YMYQEdg@mail.gmail.com \
--to=guoweikang.kernel@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox