All of lore.kernel.org
 help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com>
To: Nadav Amit <namit@vmware.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	"darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
	"guojian@oppo.com" <guojian@oppo.com>,
	"huzhanyuan@oppo.com" <huzhanyuan@oppo.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lipeifeng@oppo.com" <lipeifeng@oppo.com>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"realmz6@gmail.com" <realmz6@gmail.com>,
	"v-songbaohua@oppo.com" <v-songbaohua@oppo.com>,
	"will@kernel.org" <will@kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"yangyicong@hisilicon.com" <yangyicong@hisilicon.com>,
	"zhangshiming@oppo.com" <zhangshiming@oppo.com>
Subject: Re: [PATCH 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Fri, 8 Jul 2022 20:17:12 +1200	[thread overview]
Message-ID: <CAGsJ_4wp03dV0JqRk5NiSSEwPxvMH7z3SE0FhX8Dc8DjDPuVyw@mail.gmail.com> (raw)
In-Reply-To: <EE0C38ED-A213-4F5C-9F87-FD90E5035C21@vmware.com>

On Fri, Jul 8, 2022 at 8:08 PM Nadav Amit <namit@vmware.com> wrote:
>
> On Jul 7, 2022, at 11:59 PM, Barry Song <21cnbao@gmail.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()?

i am quite sure there are some other platforms having mm_cpumask().
for example, arm(not arm64).
but i am not exactly sure of the situation of each individual arch. thus,
i don't risk changing their source code.
but arm64 is the second platform looking for tlbbatch, and
ARCH_HAS_MM_CPUMASK only affects tlbbatch. so i would
expect those platforms to fill their ARCH_HAS_MM_CPUMASK
while they start to bringup their tlbbatch? for this moment,
we only need to make certain we don't break x86?
does it make sense?

Thanks
Barry


>

WARNING: multiple messages have this Message-ID (diff)
From: Barry Song <21cnbao@gmail.com>
To: Nadav Amit <namit@vmware.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	 "darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
	"guojian@oppo.com" <guojian@oppo.com>,
	 "huzhanyuan@oppo.com" <huzhanyuan@oppo.com>,
	 "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	 "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	 "lipeifeng@oppo.com" <lipeifeng@oppo.com>,
	"mgorman@suse.de" <mgorman@suse.de>,
	 "realmz6@gmail.com" <realmz6@gmail.com>,
	"v-songbaohua@oppo.com" <v-songbaohua@oppo.com>,
	 "will@kernel.org" <will@kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	 "yangyicong@hisilicon.com" <yangyicong@hisilicon.com>,
	"zhangshiming@oppo.com" <zhangshiming@oppo.com>
Subject: Re: [PATCH 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Fri, 8 Jul 2022 20:17:12 +1200	[thread overview]
Message-ID: <CAGsJ_4wp03dV0JqRk5NiSSEwPxvMH7z3SE0FhX8Dc8DjDPuVyw@mail.gmail.com> (raw)
In-Reply-To: <EE0C38ED-A213-4F5C-9F87-FD90E5035C21@vmware.com>

On Fri, Jul 8, 2022 at 8:08 PM Nadav Amit <namit@vmware.com> wrote:
>
> On Jul 7, 2022, at 11:59 PM, Barry Song <21cnbao@gmail.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()?

i am quite sure there are some other platforms having mm_cpumask().
for example, arm(not arm64).
but i am not exactly sure of the situation of each individual arch. thus,
i don't risk changing their source code.
but arm64 is the second platform looking for tlbbatch, and
ARCH_HAS_MM_CPUMASK only affects tlbbatch. so i would
expect those platforms to fill their ARCH_HAS_MM_CPUMASK
while they start to bringup their tlbbatch? for this moment,
we only need to make certain we don't break x86?
does it make sense?

Thanks
Barry


>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-08  8:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07 12:52 [PATCH 0/4] mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH Barry Song
2022-07-07 12:52 ` Barry Song
2022-07-07 12:52 ` [PATCH 1/4] Revert "Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64" Barry Song
2022-07-07 12:52   ` Barry Song
2022-07-07 12:52 ` [PATCH 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush Barry Song
2022-07-07 12:52   ` Barry Song
2022-07-08  6:36   ` Nadav Amit
2022-07-08  6:36     ` Nadav Amit
2022-07-08  6:59     ` Barry Song
2022-07-08  6:59       ` Barry Song
2022-07-08  8:08       ` Nadav Amit
2022-07-08  8:08         ` Nadav Amit
2022-07-08  8:17         ` Barry Song [this message]
2022-07-08  8:17           ` Barry Song
2022-07-08  8:27         ` Peter Zijlstra
2022-07-08  8:27           ` Peter Zijlstra
2022-07-11  0:30           ` Barry Song
2022-07-11  0:30             ` Barry Song
2022-07-07 12:52 ` [PATCH 3/4] mm: rmap: Extend tlbbatch APIs to fit new platforms Barry Song
2022-07-07 12:52   ` Barry Song
2022-07-07 16:43   ` Dave Hansen
2022-07-07 16:43     ` Dave Hansen
2022-07-07 21:12     ` Barry Song
2022-07-07 21:12       ` Barry Song
2022-07-07 12:52 ` [PATCH 4/4] arm64: support batched/deferred tlb shootdown during page reclamation Barry Song
2022-07-07 12:52   ` Barry Song
2022-07-07 13:49   ` Peter Zijlstra
2022-07-07 13:49     ` Peter Zijlstra
2022-07-07 21:10     ` Barry Song
2022-07-07 21:10       ` Barry Song
2022-07-08  6:21   ` Yicong Yang
2022-07-08  6:21     ` Yicong Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGsJ_4wp03dV0JqRk5NiSSEwPxvMH7z3SE0FhX8Dc8DjDPuVyw@mail.gmail.com \
    --to=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=darren@os.amperecomputing.com \
    --cc=guojian@oppo.com \
    --cc=huzhanyuan@oppo.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lipeifeng@oppo.com \
    --cc=mgorman@suse.de \
    --cc=namit@vmware.com \
    --cc=realmz6@gmail.com \
    --cc=v-songbaohua@oppo.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yangyicong@hisilicon.com \
    --cc=zhangshiming@oppo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.