Re: [PATCH v3 10/12] x86/mm: Move flush_tlb_info back to the stack

[Nadav Amit]

> On 18 Mar 2026, at 22:24, Nadav Amit <nadav.amit@xxxxxxxxx> wrote:
> 
> 
> 
>> On 18 Mar 2026, at 19:21, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
>> 
>> so it would align it properly which should result in the same cache-line
>> movement. I'm not sure about the virtual-to-physical translation of the
>> variables as in TLB misses since here we have a virtual mapped stack and
>> there we have virtual mapped per-CPU memory.
>> 
>> Here the below is my quick hack. Does this work, or still a now? I have
>> no numbers so…
>> 
>> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
>> index 5a3cdc439e38d..4a7f40c7f939a 100644
>> --- a/arch/x86/include/asm/tlbflush.h
>> +++ b/arch/x86/include/asm/tlbflush.h
>> @@ -227,7 +227,7 @@ struct flush_tlb_info {
>> 	u8 stride_shift;
>> 	u8 freed_tables;
>> 	u8 trim_cpumask;
>> -};
>> +} __aligned(SMP_CACHE_BYTES);
>> 
> 
> This would work, but you are likely to encounter the same problem PeterZ hit
> when I did something similar: in some configurations SMP_CACHE_BYTES is very
> large.

Further thinking about it and looking at the rest of the series: wouldn’t it be
simpler to put flush_tlb_info and smp_call_function_many_cond()’s
cpumask on thread_struct? It would allow to support CONFIG_CPUMASK_OFFSTACK=y
case by preallocating cpumask on thread creation.

I’m not sure whether the memory overhead is prohibitive.