Re: [PATCH v6 4/7] mm/memblock: add a reserved-region flag for poisoned frames

[Mike Rapoport <rppt@kernel.org>]

On Wed, Oct 28, 2026 at 06:49:18AM -0700, Breno Leitao wrote:
> On Wed, Oct 28, 2026 at 09:39:42AM +0100, David Hildenbrand (Arm) wrote:
> > On 10/22/26 18:33, Mike Rapoport wrote:
> > > Hi Breno,
> > > 
> > > On Fri, Oct 16, 2026 at 05:15:44AM -0700, Breno Leitao wrote:
> > >> memblock allocates from and frees to buddy whatever is not reserved, and
> > >> knows nothing about frames an earlier kernel found hardware-poisoned.
> > >> Such a frame can back the memmap, a page table or a percpu area before
> > >> any hwpoison code runs, and otherwise reaches the buddy allocator like
> > >> any other free frame.
> > >>
> > >> Add MEMBLOCK_RSRV_HWPOISON for a reserved range holding those frames.
> > > 
> > > How much this would fragment memblock.reserved?
> > > 
> > > memblock is not very scalable, to say the least, and each new flag
> > > increases the size of memblock arrays which obviously hurts performance.
> > 
> > I assume that if you have too many regions there, you have different problems
> > than scalability problems.

Not different, the problems are additive :)

> > We should cut out larger chunks, and if they are all over your address space you
> > should scrap that machine.
> 
> Ack, that is what the 2M unit does. A DRAM row fault shows up as many 4K
> pages but lands in one or two units, and adjacent units share one
> memblock.reserved region.
> 
> Mike, on the statistics you asked for: across the Meta hosts that logged
> a hard memory failure in the last 28 days, these are the
> memblock.reserved regions each host would need:
> 
>              p50   p90   p99
>      x86      1     4    41
>      arm64    1     5    27

Thanks!
A new flag is fine by me.

I'm still trying to parse what your LLM wrote in the commit messages before
sending the tags ;-)
 
> Thanks,
> --breno

-- 
Sincerely yours,
Mike.