[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOm6qnmboa3OrznkUC5BOj_EzEi-ifuVBUAhWeM+Y7Y+vM5ieA@mail.gmail.com>
Date: Mon, 6 Jan 2025 10:17:49 +0800
From: Weikang Guo <guoweikang.kernel@...il.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Mike Rapoport <rppt@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm/memblock: Modify the default failure behavior of
memblock_alloc to panic
Hi,Christophe
Christophe Leroy <christophe.leroy@...roup.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")
>
> Christophe
>
> >
Powered by blists - more mailing lists