Transparent Hugepages Are Coming To RISC-V On Linux

[phoronix]

Phoronix: Transparent Hugepages Are Coming To RISC-V On Linux

The Linux kernel's RISC-V support continues picking up remaining features not yet wired up beyond the base architecture support. The latest is transparent hugepages (THP) to be supported for RISC-V with Linux 5.14...

https://www.phoronix.com/scan.php?page=news_item&px=THP-Hugepages-For-RISC-V

[bachchain]

I realized this is a "might as well do it now before it becomes a problem" kind of thing, but are there any risc5 platforms that are even capable of supporting more than a few gigs worth of memory?

[johanb]

I realized this is a "might as well do it now before it becomes a problem" kind of thing, but are there any risc5 platforms that are even capable of supporting more than a few gigs worth of memory?

Alibaba has made 16-core designs with 2.0-2.5Ghz clock speeds. I assume that those are used together with more than just "a few gigs worth of memory".

[microcode]

I realized this is a "might as well do it now before it becomes a problem" kind of thing, but are there any risc5 platforms that are even capable of supporting more than a few gigs worth of memory?

Keep in mind that the top end of "hugepage" is 256MiB most of the time, technically up to 1GiB on Intel, and technically only 64KiB on many ARM machines; they are "huge" in the sense that default pages are usually 4KiB (except on ARMv8, 16KiB). You can buy a Mini-ITX board from SiFive right now that has 16GiB of memory, which is already 8192 2MiB megapages (in RISC-V parlance), and millions of 4KiB pages.

Then there are the big iron designs from Alibaba and Huawei, and eventually Esperanto SiFive customers, and then you have QEMU on host machines with ludicrous amounts of memory...

And then, once you support megapages (2MiB) and gigapages (1GiB), you might as well also support terapages (512GiB, only available in sv48 and larger addressing modes on RISC-V) for completeness sake.

[mangeek]

The limited memory of existing RISC-V systems is already enough to warrant THP. I think THP is underrated; I run a Minecraft server on a Raspberry Pi 4 8GB, and THP cuts down on client lag quite a bit.

TLB misses are expensive and frequent, and THP is a mature way to make a whole lot of them disappear.

[Linuxxx]

The limited memory of existing RISC-V systems is already enough to warrant THP. I think THP is underrated; I run a Minecraft server on a Raspberry Pi 4 8GB, and THP cuts down on client lag quite a bit.

TLB misses are expensive and frequent, and THP is a mature way to make a whole lot of them disappear.

You say that THP is an underrated feature...

But would you also enable it unconditionally on a desktop system like openSUSE is doing, or is the upstream default of »madvise« still the saner approach here?

[jrtc27]

It's good that Linux is finally catching up with 2019 FreeBSD (https://cgit.freebsd.org/src/commit/...76074021e4d6d4)

[mangeek]

You say that THP is an underrated feature...

But would you also enable it unconditionally on a desktop system like openSUSE is doing, or is the upstream default of »madvise« still the saner approach here?

This is way above my pay grade and FAR beyond my expertise, but I think there might be some value in making as much possible default to large pages, including swap and the page cache, then letting programs 'mUNadvise' if they want smaller pages. The current behavior would still be an option for small/embedded purposes. I have a feeling that smaller and less complicated page tables will boost performance for most uses, especially if the kernel is somewhat aggressive about keeping areas of memory available for THP allocation.

I'm guessing that a thing that happens with THP on now is that the disk cache aggressively grows to make use of unused memory (which is great), but it handles everything in 4k chunks, so when a program tries to allocate under THP, each 2MB THP makes the kernel have to 'discard' (or otherwise handle) 512 cache entries. Seems like aiming for economies of scale across the board might be beneficial. Same wth swap. If I'm swapping, I'm even more in a position where I want things handled in 2MB chunks instead of 4k at a time, and there will probably be greater compression efficiency packing two or three 2MB chunks into one 2MB swap write.