[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EE0C38ED-A213-4F5C-9F87-FD90E5035C21@vmware.com>
Date: Fri, 8 Jul 2022 08:08:45 +0000
From: Nadav Amit <namit@...are.com>
To: Barry Song <21cnbao@...il.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
Catalin Marinas <catalin.marinas@....com>,
Jonathan Corbet <corbet@....net>,
"darren@...amperecomputing.com" <darren@...amperecomputing.com>,
"guojian@...o.com" <guojian@...o.com>,
"huzhanyuan@...o.com" <huzhanyuan@...o.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"lipeifeng@...o.com" <lipeifeng@...o.com>,
"mgorman@...e.de" <mgorman@...e.de>,
"realmz6@...il.com" <realmz6@...il.com>,
"v-songbaohua@...o.com" <v-songbaohua@...o.com>,
"will@...nel.org" <will@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
"yangyicong@...ilicon.com" <yangyicong@...ilicon.com>,
"zhangshiming@...o.com" <zhangshiming@...o.com>
Subject: Re: [PATCH 2/4] mm: rmap: Allow platforms without mm_cpumask to defer
TLB flush
On Jul 7, 2022, at 11:59 PM, Barry Song <21cnbao@...il.com> wrote:
>> The cpumask_empty() is indeed just another memory access, which is most
>> likely ok. But wouldn’t adding something like CONFIG_ARCH_HAS_MM_CPUMASK
>> make the code simpler and (slightly, certainly slightly) more performant?
>
> Yep. good suggestion, Nadav. So the code will be as below, right?
Hmmm… Although it is likely to work (because only x86 and arm would use this
batch flushing), I think that for consistency ARCH_HAS_MM_CPUMASK should be
correct for all architectures.
Is it really only x86 that has mm_cpumask()?
Powered by blists - more mailing lists