Re: [PATCH v3 0/3] mm: Implement ECC handling for pfn with no struct page

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Jason Gunthorpe <jgg@nvidia.com> [251021 12:44]:
> On Tue, Oct 21, 2025 at 12:30:48PM -0400, Liam R. Howlett wrote:
> > > enables VM_PFNMAP vmas to map at PMD level. Otherwise, a poison to a PFN
> > > would need breaking the PMD mapping into PTEs to unmap only the poisoned
> > > PFN. This can have a major performance impact.
> > 
> > Is the performance impact really a concern in the event of failed
> > memory? 
> 
> Yes, something like the KVM S2 is very sensitive to page size for TLB
> performace.
> 
> > Does this happen enough to warrant this special case?
> 
> If you have a 100k sized cluster it happens constantly :\
> 
> > Surely it's not failing hardware that may cause performance impacts, so
> > is this triggered in some other way that I'm missing or a conversation
> > pointer?
> 
> It is the splitting of a pgd/pmd level into PTEs that gets mirrored
> into the S2 and then greatly increases the cost of table walks inside
> a guest. The HW caches are sized for 1G S2 PTEs, not 4k.

Ah, I see.  Seems like a worthy addition to the commit message?  I mean,
this is really a choice of throwing away memory for the benefit of tlb
performance.  Seems like a valid choice in your usecase but less so for
the average laptop.

Won't leaving the poisoned memory mapped cause migration issues?  Even
if the machine is migrated, my understanding is the poison follows
through checkpoint restore.

Thanks,
Liam