From: Barry Song <21cnbao@gmail.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
LAK <linux-arm-kernel@lists.infradead.org>, x86 <x86@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Arnd Bergmann" <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>,
"Darren Hart" <darren@os.amperecomputing.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
huzhanyuan@oppo.com, "李培锋(wink)" <lipeifeng@oppo.com>,
"张诗明(Simon Zhang)" <zhangshiming@oppo.com>, 郭健 <guojian@oppo.com>,
"real mz" <realmz6@gmail.com>,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, "Barry Song" <v-songbaohua@oppo.com>
Subject: Re: [PATCH v2 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Tue, 12 Jul 2022 10:52:24 +1200 [thread overview]
Message-ID: <CAGsJ_4wW=3xsmB1jzcv=sD9OhhPc0v=+odp=JY80vEbMY6OZ_g@mail.gmail.com> (raw)
In-Reply-To: <13b283fe-10f7-376f-9b8e-856e4d1e0ede@huawei.com>
On Tue, Jul 12, 2022 at 1:35 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> Hi Barry，
>
> On 2022/7/11 11:46, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Platforms like ARM64 have hareware TLB shootdown broadcast. They
> > don't maintain mm_cpumask but just send tlbi and related sync
> > instructions for TLB flush. task's mm_cpumask is normally empty
> > in this case. We also allow deferred TLB flush on this kind of
> > platforms.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>>
> > ---
> ...
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 169e64192e48..7bf54f57ca01 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -951,6 +951,9 @@ config ARCH_HAS_CURRENT_STACK_POINTER
> > register alias named "current_stack_pointer", this config can be
> > selected.
> >
> > +config ARCH_HAS_MM_CPUMASK
> > + bool
> > +
> > config ARCH_HAS_VM_GET_PAGE_PROT
> > bool
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 5bcb334cd6f2..13d4f9a1d4f1 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -692,6 +692,10 @@ static bool should_defer_flush(struct mm_struct *mm, enum ttu_flags flags)
> > if (!(flags & TTU_BATCH_FLUSH))
> > return false;
> >
> > +#ifndef CONFIG_ARCH_HAS_MM_CPUMASK
> > + return true;
> > +#endif
> > +
>
> Here is another option to enable arch's tlbbatch defer
>
This option is even better than simply having ARCH_HAS_MM_CPUMASK
since arch might make decisions based on specific hardware characters.
for example,
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-November/165468.html
+bool arch_tlbbatch_should_defer(struct mm_struct *mm)
+{
+ if (!radix_enabled() || cpu_has_feature(CPU_FTR_POWER9_DD1))
+ return false;
+
+ if (!mm_is_thread_local(mm))
+ return true;
+
+ return false;
+}
In this case, having MM_CPUMASK doesn't necessarily mean tlbbatch is needed.
> [1]
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20171101101735.2318-2-khandual@linux.vnet.ibm.com/
>
> > /* If remote CPUs need to be flushed then defer batch the flush */
> > if (cpumask_any_but(mm_cpumask(mm), get_cpu()) < nr_cpu_ids)
> > should_defer = true;
Thanks
Barry
WARNING: multiple messages have this Message-ID (diff)
From: Barry Song <21cnbao@gmail.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
LAK <linux-arm-kernel@lists.infradead.org>, x86 <x86@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Arnd Bergmann" <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>,
"Darren Hart" <darren@os.amperecomputing.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
huzhanyuan@oppo.com, "李培锋(wink)" <lipeifeng@oppo.com>,
"张诗明(Simon Zhang)" <zhangshiming@oppo.com>, 郭健 <guojian@oppo.com>,
"real mz" <realmz6@gmail.com>,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, "Barry Song" <v-songbaohua@oppo.com>
Subject: Re: [PATCH v2 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Tue, 12 Jul 2022 10:52:24 +1200 [thread overview]
Message-ID: <CAGsJ_4wW=3xsmB1jzcv=sD9OhhPc0v=+odp=JY80vEbMY6OZ_g@mail.gmail.com> (raw)
In-Reply-To: <13b283fe-10f7-376f-9b8e-856e4d1e0ede@huawei.com>
On Tue, Jul 12, 2022 at 1:35 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> Hi Barry，
>
> On 2022/7/11 11:46, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Platforms like ARM64 have hareware TLB shootdown broadcast. They
> > don't maintain mm_cpumask but just send tlbi and related sync
> > instructions for TLB flush. task's mm_cpumask is normally empty
> > in this case. We also allow deferred TLB flush on this kind of
> > platforms.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>>
> > ---
> ...
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 169e64192e48..7bf54f57ca01 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -951,6 +951,9 @@ config ARCH_HAS_CURRENT_STACK_POINTER
> > register alias named "current_stack_pointer", this config can be
> > selected.
> >
> > +config ARCH_HAS_MM_CPUMASK
> > + bool
> > +
> > config ARCH_HAS_VM_GET_PAGE_PROT
> > bool
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 5bcb334cd6f2..13d4f9a1d4f1 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -692,6 +692,10 @@ static bool should_defer_flush(struct mm_struct *mm, enum ttu_flags flags)
> > if (!(flags & TTU_BATCH_FLUSH))
> > return false;
> >
> > +#ifndef CONFIG_ARCH_HAS_MM_CPUMASK
> > + return true;
> > +#endif
> > +
>
> Here is another option to enable arch's tlbbatch defer
>
This option is even better than simply having ARCH_HAS_MM_CPUMASK
since arch might make decisions based on specific hardware characters.
for example,
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-November/165468.html
+bool arch_tlbbatch_should_defer(struct mm_struct *mm)
+{
+ if (!radix_enabled() || cpu_has_feature(CPU_FTR_POWER9_DD1))
+ return false;
+
+ if (!mm_is_thread_local(mm))
+ return true;
+
+ return false;
+}
In this case, having MM_CPUMASK doesn't necessarily mean tlbbatch is needed.
> [1]
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20171101101735.2318-2-khandual@linux.vnet.ibm.com/
>
> > /* If remote CPUs need to be flushed then defer batch the flush */
> > if (cpumask_any_but(mm_cpumask(mm), get_cpu()) < nr_cpu_ids)
> > should_defer = true;
Thanks
Barry
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Barry Song <21cnbao@gmail.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: "Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
Linux-MM <linux-mm@kvack.org>, 郭健 <guojian@oppo.com>,
linux-riscv@lists.infradead.org, "Will Deacon" <will@kernel.org>,
linux-s390@vger.kernel.org,
"张诗明(Simon Zhang)" <zhangshiming@oppo.com>,
"李培锋(wink)" <lipeifeng@oppo.com>,
"Jonathan Corbet" <corbet@lwn.net>, x86 <x86@kernel.org>,
linux-mips@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"real mz" <realmz6@gmail.com>,
"Barry Song" <v-songbaohua@oppo.com>,
openrisc@lists.librecores.org,
"Darren Hart" <darren@os.amperecomputing.com>,
LAK <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
huzhanyuan@oppo.com, "Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Tue, 12 Jul 2022 10:52:24 +1200 [thread overview]
Message-ID: <CAGsJ_4wW=3xsmB1jzcv=sD9OhhPc0v=+odp=JY80vEbMY6OZ_g@mail.gmail.com> (raw)
In-Reply-To: <13b283fe-10f7-376f-9b8e-856e4d1e0ede@huawei.com>
On Tue, Jul 12, 2022 at 1:35 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> Hi Barry，
>
> On 2022/7/11 11:46, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Platforms like ARM64 have hareware TLB shootdown broadcast. They
> > don't maintain mm_cpumask but just send tlbi and related sync
> > instructions for TLB flush. task's mm_cpumask is normally empty
> > in this case. We also allow deferred TLB flush on this kind of
> > platforms.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>>
> > ---
> ...
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 169e64192e48..7bf54f57ca01 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -951,6 +951,9 @@ config ARCH_HAS_CURRENT_STACK_POINTER
> > register alias named "current_stack_pointer", this config can be
> > selected.
> >
> > +config ARCH_HAS_MM_CPUMASK
> > + bool
> > +
> > config ARCH_HAS_VM_GET_PAGE_PROT
> > bool
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 5bcb334cd6f2..13d4f9a1d4f1 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -692,6 +692,10 @@ static bool should_defer_flush(struct mm_struct *mm, enum ttu_flags flags)
> > if (!(flags & TTU_BATCH_FLUSH))
> > return false;
> >
> > +#ifndef CONFIG_ARCH_HAS_MM_CPUMASK
> > + return true;
> > +#endif
> > +
>
> Here is another option to enable arch's tlbbatch defer
>
This option is even better than simply having ARCH_HAS_MM_CPUMASK
since arch might make decisions based on specific hardware characters.
for example,
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-November/165468.html
+bool arch_tlbbatch_should_defer(struct mm_struct *mm)
+{
+ if (!radix_enabled() || cpu_has_feature(CPU_FTR_POWER9_DD1))
+ return false;
+
+ if (!mm_is_thread_local(mm))
+ return true;
+
+ return false;
+}
In this case, having MM_CPUMASK doesn't necessarily mean tlbbatch is needed.
> [1]
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20171101101735.2318-2-khandual@linux.vnet.ibm.com/
>
> > /* If remote CPUs need to be flushed then defer batch the flush */
> > if (cpumask_any_but(mm_cpumask(mm), get_cpu()) < nr_cpu_ids)
> > should_defer = true;
Thanks
Barry
WARNING: multiple messages have this Message-ID (diff)
From: Barry Song <21cnbao@gmail.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
LAK <linux-arm-kernel@lists.infradead.org>, x86 <x86@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Arnd Bergmann" <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>,
"Darren Hart" <darren@os.amperecomputing.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
huzhanyuan@oppo.com, "李培锋(wink)" <lipeifeng@oppo.com>,
"张诗明(Simon Zhang)" <zhangshiming@oppo.com>, 郭健 <guojian@oppo.com>,
"real mz" <realmz6@gmail.com>,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, "Barry Song" <v-songbaohua@oppo.com>
Subject: Re: [PATCH v2 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush
Date: Tue, 12 Jul 2022 10:52:24 +1200 [thread overview]
Message-ID: <CAGsJ_4wW=3xsmB1jzcv=sD9OhhPc0v=+odp=JY80vEbMY6OZ_g@mail.gmail.com> (raw)
In-Reply-To: <13b283fe-10f7-376f-9b8e-856e4d1e0ede@huawei.com>
On Tue, Jul 12, 2022 at 1:35 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> Hi Barry，
>
> On 2022/7/11 11:46, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Platforms like ARM64 have hareware TLB shootdown broadcast. They
> > don't maintain mm_cpumask but just send tlbi and related sync
> > instructions for TLB flush. task's mm_cpumask is normally empty
> > in this case. We also allow deferred TLB flush on this kind of
> > platforms.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>>
> > ---
> ...
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 169e64192e48..7bf54f57ca01 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -951,6 +951,9 @@ config ARCH_HAS_CURRENT_STACK_POINTER
> > register alias named "current_stack_pointer", this config can be
> > selected.
> >
> > +config ARCH_HAS_MM_CPUMASK
> > + bool
> > +
> > config ARCH_HAS_VM_GET_PAGE_PROT
> > bool
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 5bcb334cd6f2..13d4f9a1d4f1 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -692,6 +692,10 @@ static bool should_defer_flush(struct mm_struct *mm, enum ttu_flags flags)
> > if (!(flags & TTU_BATCH_FLUSH))
> > return false;
> >
> > +#ifndef CONFIG_ARCH_HAS_MM_CPUMASK
> > + return true;
> > +#endif
> > +
>
> Here is another option to enable arch's tlbbatch defer
>
This option is even better than simply having ARCH_HAS_MM_CPUMASK
since arch might make decisions based on specific hardware characters.
for example,
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-November/165468.html
+bool arch_tlbbatch_should_defer(struct mm_struct *mm)
+{
+ if (!radix_enabled() || cpu_has_feature(CPU_FTR_POWER9_DD1))
+ return false;
+
+ if (!mm_is_thread_local(mm))
+ return true;
+
+ return false;
+}
In this case, having MM_CPUMASK doesn't necessarily mean tlbbatch is needed.
> [1]
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20171101101735.2318-2-khandual@linux.vnet.ibm.com/
>
> > /* If remote CPUs need to be flushed then defer batch the flush */
> > if (cpumask_any_but(mm_cpumask(mm), get_cpu()) < nr_cpu_ids)
> > should_defer = true;
Thanks
Barry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-07-11 22:52 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 3:46 [PATCH v2 0/4] mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` [PATCH v2 1/4] Revert "Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64" Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` [PATCH v2 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 13:35 ` Kefeng Wang
2022-07-11 13:35 ` Kefeng Wang
2022-07-11 13:35 ` Kefeng Wang
2022-07-11 13:35 ` Kefeng Wang
2022-07-11 22:52 ` Barry Song [this message]
2022-07-11 22:52 ` Barry Song
2022-07-11 22:52 ` Barry Song
2022-07-11 22:52 ` Barry Song
2022-07-11 3:46 ` [PATCH v2 3/4] mm: rmap: Extend tlbbatch APIs to fit new platforms Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` [PATCH v2 4/4] arm64: support batched/deferred tlb shootdown during page reclamation Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-11 3:46 ` Barry Song
2022-07-14 3:28 ` [PATCH v2 0/4] mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH Xin Hao
2022-07-14 3:28 ` Xin Hao
2022-07-14 3:28 ` Xin Hao
2022-07-14 3:28 ` Xin Hao
2022-07-14 4:51 ` Barry Song
2022-07-14 4:51 ` Barry Song
2022-07-14 4:51 ` Barry Song
2022-07-14 4:51 ` Barry Song
2022-07-15 2:47 ` Yicong Yang
2022-07-15 2:47 ` Yicong Yang
2022-07-15 2:47 ` Yicong Yang
2022-07-15 2:47 ` Yicong Yang
2022-07-18 13:28 ` Yicong Yang
2022-07-18 13:28 ` Yicong Yang
2022-07-18 13:28 ` Yicong Yang
2022-07-18 13:28 ` Yicong Yang
2022-07-20 11:18 ` Barry Song
2022-07-20 11:18 ` Barry Song
2022-07-20 11:18 ` Barry Song
2022-07-20 11:18 ` Barry Song
2022-07-23 9:22 ` xhao
2022-07-23 9:22 ` xhao
2022-07-23 9:22 ` xhao
2022-07-23 9:22 ` xhao
2022-07-23 9:17 ` xhao
2022-07-23 9:17 ` xhao
2022-07-23 9:17 ` xhao
2022-07-23 9:17 ` xhao
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_4wW=3xsmB1jzcv=sD9OhhPc0v=+odp=JY80vEbMY6OZ_g@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-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lipeifeng@oppo.com \
--cc=openrisc@lists.librecores.org \
--cc=realmz6@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=wangkefeng.wang@huawei.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.