[External] Page sizes supported by RISC-V

[Xu Lu]

Hi Florian,


On Sun, Sep 29, 2024 at 12:36 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> I'm working on adding a <sys/pagesize.h> header to glibc, so that
> programmers can easily determine the range of possible page sizes for a
> particular target, for things like pointer tagging and mapped file
> alignment requirements.
>
> Linux currently supports 4 KiB pages only.  I couldn't find anything in
> the RISC-V specifications that mandates a specific page size, but of
> course the way ELF LOAD segments are constructed necessarily imposes a
> maximum page size constraint for particular executables.  Today, the
> toolchain assumes the maximum supported page size is 4 KiB, and this is
> also reflected in arch/riscv/Kconfig in the Linux sources (as far as I
> can read Kconfig).

Yes, RISC-V kernel supports only 4K page size now. I personally tend
to support more page sizes. We have tested 64K kernel performance on
ARM Ampere Altra platform and found multiple memory-intensive apps'
performance based on 64K page kernel is significantly higher than that
on 4K page kernel.

>
> I found a previous proposal for kernel support of 64 KiB pages:
>
>   [RFC PATCH V1 00/11] riscv: Introduce 64K base page
>   <https://lore.kernel.org/linux-riscv/20231123065708.91345-1-luxu.kernel@bytedance.com/>

This is our first version of 64K page implementation[0], which is
based on Svnapot extension as RISC-V does not support 64K MMU yet. The
main idea of it is allocating/mapping pages in 64K granularity and
always applying Svnapot on ptes. The first version is only a demo and
still has some bugs. We have fixed existing problems and tested its
performance, but found that its performance benefit is not as
significant as we received on ARM 64K. We think the performance
benefit degradation mainly comes from software logic of imitating 64K.
For example, when need to tlb flush a page, instead of using a single
tlb flush instruction, we have to flush all 4K pages of a single 64K
page in a loop logic. And when need to check pte access/dirty bit,
instead of checking a single pte, we have to check all 4K ptes of a
single 64K page in a loop logic. The next version of patches and its
performance data is still being organized and will be published as
soon as possible.

Thus, we are also trying to call for native 64K MMU in RISC-V
community. You can find the discussion in link [1]. We hope more
people can participate in the discussion and provide more data
support.

[0] https://lore.kernel.org/linux-riscv/20231123065708.91345-1-luxu.kernel@bytedance.com/
[1] https://lists.riscv.org/g/tech-privileged/topic/query_about_risc_v_s_support/108641509

Best regards,

Xu Lu

>
> Is this something we should consider today?
>
> I'm leaning towards teaching glibc that the RISC-V page size is always
> 4 KiB because given the current toolchain defaults, it's necessary
> to rebuild the world anyway if supported page sizes ever change.
>
> Thanks,
> Florian
>