All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: linux-riscv@lists.infradead.org
Cc: Jeff Law <jeffreyalaw@gmail.com>,
	Palmer Dabbelt <palmer@rivosinc.com>,
	Xu Lu <luxu.kernel@bytedance.com>
Subject: Page sizes supported by RISC-V
Date: Sat, 28 Sep 2024 18:35:46 +0200	[thread overview]
Message-ID: <878qvbzqfx.fsf@oldenburg.str.redhat.com> (raw)

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).

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/>

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


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

             reply	other threads:[~2024-09-28 16:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28 16:35 Florian Weimer [this message]
2024-09-29  3:29 ` [External] Page sizes supported by RISC-V Xu Lu
2024-09-29  5:04   ` Florian Weimer
2024-09-29  5:18     ` Xu Lu
2024-09-29 14:51 ` Jeff Law
2024-09-29 15:08   ` Florian Weimer
2024-09-29 15:18     ` Jeff Law
2024-09-29 15:49       ` Maciej W. Rozycki
2024-10-02 15:25         ` Palmer Dabbelt
2025-01-15  2:00       ` Jeff Law
2025-01-15  6:51         ` Maciej W. Rozycki
2025-01-15  7:51           ` Florian Weimer
2025-01-15  9:03             ` Maciej W. Rozycki
2025-01-15 14:58             ` Jeff Law

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=878qvbzqfx.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=luxu.kernel@bytedance.com \
    --cc=palmer@rivosinc.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.