Hi,Christophe, Andrew
Weikang Guo <guoweikang.kernel@xxxxxxxxx> 于2025年1月6日周一 10:17写道：
>
> Hi,Christophe
>
> Christophe Leroy <christophe.leroy@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx/
- Drop memblock_alloc_nopanic：
https://lore.kernel.org/lkml/1548057848-15136-1-git-send-email-rppt@xxxxxxxxxxxxx/
> >
> > Christophe
> >
> > >
