Re: [PATCH] x86/mm: Revert INVLPGB optimization for set_memory code

[Dave Hansen <dave.hansen@intel.com>]

On 4/22/26 00:59, Hellstrom, Thomas wrote:
> On Tue, 2026-04-21 at 11:46 -0700, Dave Hansen wrote:
>> On 4/21/26 11:42, Edgecombe, Rick P wrote:
>>> Makes sense. And I see the merit in just trying to revert the
>>> change. But I
>>> think a change to fix the optimization is also temptingly small:
>>
>> Yeah, it is tempting. It's probably what I would have done if this
>> wasn't easy to revert, or if it wasn't _just_ an optimization.
>>
>> But once -rc1 hits, we should definitely revisit the optimization.
> 
> Are there any timings available for how bad a global TLB flush affects
> system performance vs a single IPI invalidating a limited set of TLB
> entries that aren't likely to be re-populated soon?
> An uneducated guess would probably always favor the latter.

Not in a while. I ran a bunch of numbers a decade or so ago and that's
where the /sys/kernel/debug/x86/tlb_single_page_flush_ceiling default
came from. But that was mostly focused on userspace and before PCIDs if
I remember right.

Rik also looked at some things recently on the AMD side when he was
trying to figure out when to use INVLPGB versus IPIs.

> The set_pages_array_wc() is unfortunately a rather common operation
> when allocating integrated graphics buffer objects. At least until a
> pool of WC pages has been established by the graphics drivers. And I
> think when this is happening it's reasonable to accept a predictable
> allocation delay vs to have the full TLB invalidated across all cores
> repeatedly?

Heh, I'd worry about shattering the direct map first. That costs a
performance penalty on everything, all the time, forever, before I
worried about a few measly one-off global TLB flushes.

There are a million ways to make all of this better. For instance,
during boot, the drm_gem_get_pages() are *probably* physically
contiguous, despite being stored in a ->pages[] array. The cpa code
could look for that. It could also be more careful about INVLPG versus
full flushes when shattering large pages.

But it would need an actual investigation with actual data before we
could make reasonable progress.