[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <14f91337-ac7d-52f7-bc86-4091bec4d099@intel.com>
Date: Mon, 26 Jun 2023 08:23:19 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: ypodemsk@...hat.com, mtosatti@...hat.com, ppandit@...hat.com,
david@...hat.com, linux@...linux.org.uk, mpe@...erman.id.au,
npiggin@...il.com, christophe.leroy@...roup.eu, hca@...ux.ibm.com,
gor@...ux.ibm.com, agordeev@...ux.ibm.com,
borntraeger@...ux.ibm.com, svens@...ux.ibm.com,
davem@...emloft.net, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
keescook@...omium.org, paulmck@...nel.org, frederic@...nel.org,
will@...nel.org, peterz@...radead.org, ardb@...nel.org,
samitolvanen@...gle.com, juerg.haefliger@...onical.com,
arnd@...db.de, rmk+kernel@...linux.org.uk, geert+renesas@...der.be,
linus.walleij@...aro.org, akpm@...ux-foundation.org,
sebastian.reichel@...labora.com, rppt@...nel.org,
aneesh.kumar@...ux.ibm.com, x86@...nel.org,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
sparclinux@...r.kernel.org, linux-arch@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp_sync IPI
only to MM CPUs
On 6/26/23 07:36, ypodemsk@...hat.com wrote:
> On Thu, 2023-06-22 at 06:37 -0700, Dave Hansen wrote:
>> On 6/22/23 06:14, ypodemsk@...hat.com wrote:
>>> I will send a new version with the local variable as you suggested
>>> soon.
>>> As for the config name, what about CONFIG_ARCH_HAS_MM_CPUMASK?
>>
>> The confusing part about that name is that mm_cpumask() and
>> mm->cpu_bitmap[] are defined unconditionally. So, they're *around*
>> unconditionally but just aren't updated.
>>
> I think your right about the config name,
> How about the
> CONFIG_ARCH_USE_MM_CPUMASK?
> This has the right semantic as these archs use the cpumask field of the
> mm struct.
"USE" is still a command. It should, at worst, be "USES". But that's
still kinda generic. How about:
CONFIG_ARCH_UPDATES_MM_CPUMASK
?
>> BTW, it would also be nice to have _some_ kind of data behind this
>> patch.
>>
>> Fewer IPIs are better I guess, but it would still be nice if you
>> could say:
>>
>> Before this patch, /proc/interrupts showed 123 IPIs/hour for an
>> isolated CPU. After the approach here, it was 0.
>>
>> ... or something.
>
> This is part of an ongoing effort to remove IPIs and this one was found
> via code inspection.
OK, so it should be something more like:
This was found via code inspection, but fixing it isn't very
important so we didn't bother to test it any more than just
making sure the thing still boots when it is applied.
Does that cover it?
Powered by blists - more mailing lists