Re: [PATCH v6 12/12] x86/mm: Enable preemption during flush_tlb_kernel_range

[Chuyi Zhou]

On 2026-06-05 5:21 a.m., Dave Hansen wrote:
> On 5/28/26 08:13, Chuyi Zhou wrote:
>> -	info->initiating_cpu	= smp_processor_id();
>> +	info->initiating_cpu	= raw_smp_processor_id();
>>   	info->trim_cpumask	= 0;
>>   }
> 
> Doesn't this turn ->initiating_cpu into garbage? It doesn't mean
> anything any more other than being a random record of the past.
> 
> I think it's just used for stats, so not the end of the world. But, the
> warning is there for a *REASON*. Please don't just turn it off and
> ignore the fallout.
> 
> I'm also just generally not sure this is worth it. Kernel TLB flushes
> stink. This just makes them stink slightly less. Maybe imperceptibly so.
> 
> Is it worth the churn?

Sebastian raised a similar concern earlier[1-2]. The kernel range path 
does not really need a full flush_tlb_info: kernel_tlb_flush_all() does 
not need it at all, and the range case only needs start/end. But doing 
that properly means refactoring the kernel TLB flush path, which would 
add more churn to this series.

Given your concern about whether this part is worth it, I think the best
approach is to drop the flush_tlb_kernel_range() preemption patch
from this series. That keeps get_flush_tlb_info() using
smp_processor_id(), avoids making ->initiating_cpu meaningless after
migration, and keeps the current series focused on the mm TLB flush path.

If we still want to optimize flush_tlb_kernel_range(), I can do that
later as a separate patchset, starting with a cleanup that separates the
kernel range/full flush data from struct flush_tlb_info.

[1]https://lore.kernel.org/lkml/20260522104818.CbT5fyN8@xxxxxxxxxxxxx/
[2]https://lore.kernel.org/lkml/6265669c-d7d4-45a4-a9d2-2f5e884aa7c5@xxxxxxxxxxxxx/