From: Breno Leitao <leitao@debian.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
kas@kernel.org, kexec@lists.infradead.org,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Oscar Salvador <osalvador@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
hannes@cmpxchg.or, shakeel.butt@linux.dev,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, rmikey@meta.com, riel@surriel.com,
harry@kernel.org, linux-cxl@vger.kernel.org,
driver-core@lists.linux.dev, kernel-team@meta.com
Subject: Re: [PATCH v5 7/9] drivers/base/memory: count inherited poisoned frames into the block
Date: Wed, 16 Sep 2026 02:35:06 -0700 [thread overview]
Message-ID: <aqpczrtIwSG948iv@gmail.com> (raw)
In-Reply-To: <de41b78a-8471-4832-be0c-35d410a4499a@kernel.org>
Hello David,
First of all, thanks for your time looking at this patchset.
On Wed, Sep 16, 2026 at 08:48:56AM +0200, David Hildenbrand (Arm) wrote:
> On 9/15/26 14:53, Breno Leitao wrote:
> > +static void memblk_nr_poison_init(struct memory_block *mem)
> > +{
> > + unsigned long pfn = section_nr_to_pfn(mem->start_section_nr);
> > + unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
> > + unsigned long i, nr_poison = 0;
> > +
> > + /* A hotplugged block is created before its pages are online. */
> > + if (mem->state != MEM_ONLINE)
> > + return;
> > +
> > + if (!range_contains_poisoned_memory(PFN_PHYS(pfn),
> > + nr_pages << PAGE_SHIFT))
> > + return;
> > +
> > + for (i = 0; i < nr_pages; i++) {
> > + struct page *page = pfn_to_online_page(pfn + i);
> > +
> > + if (page && PageHWPoison(page))
> > + nr_poison++;
> > + }
>
> That just slows down boot unnecessarily on 99.9999999999999999999% of all
> systems out there.
hmmm, I am not sure I see it that way.
The loop only runs for a block the bitmap marks. On a machine with nothing
recorded the bitmap is all zeros, the range_contains_poisoned_memory() check
right above it returns false, and the loop never executes.
What every boot does pay is that check, once per block. The stub installs
the table whether or not anything was ever recorded in it, so this is not a
NULL test: it is two 64-bit divisions by the unit size plus a
find_next_bit() over the single word a 128M block covers at one bit per 2M.
The real cost (that "for loop above"), comes when you kexec (not on cold
boot -- given the bitmap is empty), and you are trying to init
a memory block that has poisoned pages into it. Which seems the right
trade-off, no?
That said, can we do better? Yes. The silly win is to let the table say
whether anything was ever recorded in it, something like a
linux_efi_poisoned_memory->empty that the first recorded frame clears,
and return on that before the bitmap is reached at all.
Is this what you are looking for, or something more drastic?
Thanks for your review,
--breno
next prev parent reply other threads:[~2026-09-16 9:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 12:53 [PATCH v5 0/9] mm/memory-failure: keep hardware-poisoned pages out of the next kexec Breno Leitao
2026-09-15 12:53 ` [PATCH v5 1/9] mm/page_alloc: factor out the accept-and-free tail of __free_pages_core() Breno Leitao
2026-09-15 12:57 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 2/9] mm/memory-failure: efi: add the LINUX_EFI_POISONED_MEMORY configuration table Breno Leitao
2026-09-15 13:05 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 3/9] mm/memory-failure: libstub: install the poisoned-memory EFI table Breno Leitao
2026-09-15 13:15 ` sashiko-bot
2026-09-15 14:00 ` Breno Leitao
2026-09-16 15:39 ` Usama Arif
2026-09-15 12:53 ` [PATCH v5 4/9] mm/memory-failure: efi: adopt the inherited poisoned-memory table Breno Leitao
2026-09-15 13:24 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 5/9] mm/memory-failure: efi: record hardware-poisoned frames into the " Breno Leitao
2026-09-15 13:36 ` sashiko-bot
2026-09-15 14:33 ` Breno Leitao
2026-09-15 12:53 ` [PATCH v5 6/9] mm/memory-failure: efi: answer whether a range is poisoned Breno Leitao
2026-09-15 13:45 ` sashiko-bot
2026-09-16 6:44 ` David Hildenbrand (Arm)
2026-09-15 12:53 ` [PATCH v5 7/9] drivers/base/memory: count inherited poisoned frames into the block Breno Leitao
2026-09-15 13:59 ` sashiko-bot
2026-09-16 6:48 ` David Hildenbrand (Arm)
2026-09-16 9:35 ` Breno Leitao [this message]
2026-09-16 14:51 ` David Hildenbrand (Arm)
2026-09-15 12:53 ` [PATCH v5 8/9] mm/memory-failure: add hwpoison_boot_page() to flag an inherited frame Breno Leitao
2026-09-15 14:11 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 9/9] mm/memory-failure: keep inherited poisoned frames out of the buddy allocator Breno Leitao
2026-09-15 14:25 ` sashiko-bot
2026-09-16 8:32 ` Vlastimil Babka (SUSE)
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=aqpczrtIwSG948iv@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brendan.jackman@linux.dev \
--cc=dakr@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.or \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=x86@kernel.org \
--cc=ziy@nvidia.com \
/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
all inboxes | Powered by JetHome®