From: "Arnd Bergmann" <arnd@arndb.de>
To: "Xu Lu" <luxu.kernel@bytedance.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Anup Patel" <anup@brainfault.org>,
"Atish Patra" <atishp@atishpatra.org>
Cc: dengliang.1214@bytedance.com,
"Xie Yongji" <xieyongji@bytedance.com>,
lihangjing@bytedance.com,
"Muchun Song" <songmuchun@bytedance.com>,
punit.agrawal@bytedance.com, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [RFC PATCH V1 00/11] riscv: Introduce 64K base page
Date: Thu, 23 Nov 2023 10:29:22 +0100 [thread overview]
Message-ID: <94c2e04c-4c62-4ee1-8ae7-cbd675c5064e@app.fastmail.com> (raw)
In-Reply-To: <20231123065708.91345-1-luxu.kernel@bytedance.com>
On Thu, Nov 23, 2023, at 07:56, Xu Lu wrote:
> Some existing architectures like ARM supports base page larger than 4K
> as their MMU supports more page sizes. Thus, besides hugetlb page and
> transparent huge page, there is another way for these architectures to
> enjoy the benefits of fewer TLB misses without worrying about cost of
> splitting and merging huge pages. However, on architectures with only
> 4K MMU, larger base page is unavailable now.
>
> This patch series attempts to break through the limitation of MMU and
> supports larger base page on RISC-V, which only supports 4K page size
> now.
>
> The key idea to implement larger base page based on 4K MMU is to
> decouple the MMU page from the base page in view of kernel mm, which we
> denote as software page. In contrary to software page, we denote the MMU
> page as hardware page. Below is the difference between these two kinds
> of pages.
We have played with this on arm32, but the conclusion is that it's
almost never worth the memory overhead, as most workloads end up
using several times the amount of physical RAM after each small
file in the page cache and any sparse populated anonymous memory
area explodes to up to 16 times the size.
On ppc64, using 64KB pages was way to get around limitations in
their hashed MMU design, which had a much bigger performance impact
because any page table access ends up being a cache miss. On arm64,
there are some CPUs like the Fujitsu A64FX that are really bad at
4KB pages and don't support 16KB pages, so this is the only real
option.
You will see a notable performance benefit in synthetic benchmarks
like speccpu with 64KB pages, or on specific computational
workloads that have large densely packed memory chunks, but for
real workloads, the usual answer is to just use transparent
hugepages for larger mappings and a page size of no more than
16KB for the page cache.
With the work going into using folios in the kernel (see e.g.
https://lwn.net/Articles/932386/), even the workloads that
benefit from 64KB base pages should be better off with 4KB
pages and just using the TLB hints for large folios.
Arnd
next prev parent reply other threads:[~2023-11-23 9:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 6:56 Xu Lu
2023-11-23 6:56 ` [RFC PATCH V1 01/11] mm: Fix misused APIs on huge pte Xu Lu
2023-12-31 16:39 ` Alexandre Ghiti
2024-01-04 7:59 ` [External] " Xu Lu
2023-11-23 6:56 ` [RFC PATCH V1 02/11] riscv: Introduce concept of hardware base page Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 03/11] riscv: Adapt pte struct to gap between hw page and sw page Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 04/11] riscv: Adapt pte operations " Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 05/11] riscv: Decouple pmd operations and pte operations Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 06/11] riscv: Distinguish pmd huge pte and napot huge pte Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 07/11] riscv: Adapt satp operations to gap between hw page and sw page Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 08/11] riscv: Apply Svnapot for base page mapping Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 09/11] riscv: Adjust fix_btmap slots number to match variable page size Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 10/11] riscv: kvm: Adapt kvm to gap between hw page and sw page Xu Lu
2023-11-23 6:57 ` [RFC PATCH V1 11/11] riscv: Introduce 64K page size Xu Lu
2023-11-23 9:29 ` Arnd Bergmann [this message]
2023-11-27 8:14 ` [External] Re: [RFC PATCH V1 00/11] riscv: Introduce 64K base page Xu Lu
2023-12-07 6:07 ` Xu Lu
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=94c2e04c-4c62-4ee1-8ae7-cbd675c5064e@app.fastmail.com \
--to=arnd@arndb.de \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=atishp@atishpatra.org \
--cc=dengliang.1214@bytedance.com \
--cc=lihangjing@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luxu.kernel@bytedance.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=punit.agrawal@bytedance.com \
--cc=songmuchun@bytedance.com \
--cc=xieyongji@bytedance.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
all inboxes | Powered by JetHome®