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

[Breno Leitao <leitao@debian.org>]

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.
> 
> 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,
--breno