From: Barry Song <21cnbao@gmail.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: wangkefeng.wang@huawei.com, prime.zeng@hisilicon.com,
linux-doc@vger.kernel.org, peterz@infradead.org,
catalin.marinas@arm.com, yangyicong@hisilicon.com,
linux-mm@kvack.org, Nadav Amit <namit@vmware.com>,
guojian@oppo.com, linux-riscv@lists.infradead.org,
will@kernel.org, linux-s390@vger.kernel.org,
zhangshiming@oppo.com, lipeifeng@oppo.com, corbet@lwn.net,
x86@kernel.org, Mel Gorman <mgorman@suse.de>,
linux-mips@vger.kernel.org, arnd@arndb.de, realmz6@gmail.com,
Barry Song <v-songbaohua@oppo.com>,
openrisc@lists.librecores.org, darren@os.amperecomputing.com,
linux-arm-kernel@lists.infradead.org, xhao@linux.alibaba.com,
linux-kernel@vger.kernel.org, huzhanyuan@oppo.com,
Yicong Yang <yangyicong@huawei.com>,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 2/2] arm64: support batched/deferred tlb shootdown during page reclamation
Date: Fri, 28 Oct 2022 11:07:58 +1300 [thread overview]
Message-ID: <CAGsJ_4x0KhEjm5a9jhtS+YK1AT49u3sHnp2rHZVSuTGZp4nKzA@mail.gmail.com> (raw)
In-Reply-To: <ecd161db-b290-7997-a81e-a0a00bd1c599@arm.com>
On Thu, Oct 27, 2022 at 11:42 PM Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
>
>
> On 9/28/22 05:53, Barry Song wrote:
> > On Tue, Sep 27, 2022 at 10:15 PM Yicong Yang <yangyicong@huawei.com> wrote:
> >>
> >> On 2022/9/27 14:16, Anshuman Khandual wrote:
> >>> [...]
> >>>
> >>> On 9/21/22 14:13, Yicong Yang wrote:
> >>>> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
> >>>> +{
> >>>> + /* for small systems with small number of CPUs, TLB shootdown is cheap */
> >>>> + if (num_online_cpus() <= 4)
> >>>
> >>> It would be great to have some more inputs from others, whether 4 (which should
> >>> to be codified into a macro e.g ARM64_NR_CPU_DEFERRED_TLB, or something similar)
> >>> is optimal for an wide range of arm64 platforms.
> >>>
> >
> > I have tested it on a 4-cpus and 8-cpus machine. but i have no machine
> > with 5,6,7
> > cores.
> > I saw improvement on 8-cpus machines and I found 4-cpus machines don't need
> > this patch.
> >
> > so it seems safe to have
> > if (num_online_cpus() < 8)
> >
> >>
> >> Do you prefer this macro to be static or make it configurable through kconfig then
> >> different platforms can make choice based on their own situations? It maybe hard to
> >> test on all the arm64 platforms.
> >
> > Maybe we can have this default enabled on machines with 8 and more cpus and
> > provide a tlbflush_batched = on or off to allow users enable or
> > disable it according
> > to their hardware and products. Similar example: rodata=on or off.
>
> No, sounds bit excessive. Kernel command line options should not be added
> for every possible run time switch options.
>
> >
> > Hi Anshuman, Will, Catalin, Andrew,
> > what do you think about this approach?
> >
> > BTW, haoxin mentioned another important user scenarios for tlb bach on arm64:
> > https://lore.kernel.org/lkml/393d6318-aa38-01ed-6ad8-f9eac89bf0fc@linux.alibaba.com/
> >
> > I do believe we need it based on the expensive cost of tlb shootdown in arm64
> > even by hardware broadcast.
>
> Alright, for now could we enable ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH selectively
> with CONFIG_EXPERT and for num_online_cpus() > 8 ?
Sounds good to me. It is a good start to bring up tlb batched flush in
ARM64. Later on, we
might want to see it in both memory reclamation and migration.
Thanks
Barry
next prev parent reply other threads:[~2022-10-27 22:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 8:43 [PATCH v4 0/2] mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH Yicong Yang
2022-09-21 8:43 ` [PATCH v4 1/2] mm/tlbbatch: Introduce arch_tlbbatch_should_defer() Yicong Yang
2022-09-21 8:54 ` Barry Song
2022-09-21 8:43 ` [PATCH v4 2/2] arm64: support batched/deferred tlb shootdown during page reclamation Yicong Yang
2022-09-27 6:16 ` Anshuman Khandual
2022-09-27 9:15 ` Yicong Yang
2022-09-28 0:23 ` Barry Song
2022-10-27 10:41 ` Anshuman Khandual
2022-10-27 14:19 ` Punit Agrawal
2022-10-27 21:55 ` Barry Song
2022-10-28 2:14 ` Anshuman Khandual
2022-10-28 13:12 ` Punit Agrawal
2022-10-28 1:20 ` Yicong Yang
2022-10-28 13:11 ` Punit Agrawal
2022-10-28 21:40 ` Barry Song
2022-10-31 18:36 ` Punit Agrawal
2022-10-27 22:07 ` Barry Song [this message]
2022-10-28 1:56 ` Anshuman Khandual
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_4x0KhEjm5a9jhtS+YK1AT49u3sHnp2rHZVSuTGZp4nKzA@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--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=mgorman@suse.de \
--cc=namit@vmware.com \
--cc=openrisc@lists.librecores.org \
--cc=peterz@infradead.org \
--cc=prime.zeng@hisilicon.com \
--cc=realmz6@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xhao@linux.alibaba.com \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).