Re: [RFC PATCH v7 30/31] x86/mm, mm/vmalloc: Defer kernel TLB flush IPIs under CONFIG_COALESCE_TLBI=y

[Andy Lutomirski]

On Wed, Nov 19, 2025, at 10:31 AM, Dave Hansen wrote:
> On 11/14/25 07:14, Valentin Schneider wrote:
>> +static bool flush_tlb_kernel_cond(int cpu, void *info)
>> +{
>> +    return housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE) ||
>> +           per_cpu(kernel_cr3_loaded, cpu);
>> +}
>
> Is it OK that 'kernel_cr3_loaded' can be be stale? Since it's not part
> of the instruction that actually sets CR3, there's a window between when
> 'kernel_cr3_loaded' is set (or cleared) and CR3 is actually written.
>
> Is that OK?
>
> It seems like it could lead to both unnecessary IPIs being sent and for
> IPIs to be missed.

I read the code earlier today and I *think* it’s maybe okay. It’s quite 
confusing that this thing is split among multiple patches, and the memory 
ordering issues need comments.

The fact that the big flush is basically unconditional at this point helps. The 
fact that it’s tangled up with CR3 even though the current implementation has 
nothing to do with CR3 does not help.

I’m kind of with dhansen though — the fact that the implementation is so nasty 
coupled with the fact that modern CPUs can do this in hardware makes the whole 
thing kind of unpalatable.

>
> I still _really_ wish folks would be willing to get newer CPUs to get
> this behavior rather than going through all this complexity. RAR in
> particular was *specifically* designed to keep TLB flushing IPIs from
> blipping userspace for too long.