Hacker News Reader

Comment by rwmj | Hacker News Reader

RHEL used 64k page size on aarch64 for a while. I believe we have switched back to 4k. It caused some problems, from memory:

* Blow-ups in various kernel data structures. There was some virtio code which was allocating N pages per driver queue.

* Problems with GPUs, either the driver or the firmware assumed 4k pages. (Edit: This actually affected Power, not ARM, but the issue is caused by page size: https://lists.fedoraproject.org/archives/list/devel@lists.fe...)

* Filesystems make assumptions about page size versus block size.

* Processes generally take more RAM, with RAM wasted because of internal fragmentation.

View on HN

> RHEL used 64k page size on aarch64 for a while. I believe we have switched back to 4k.

Last I checked, at least CentOS 8 (which should be the same as RHEL 8) is still using 64k pages (search at https://git.centos.org/rpms/kernel/blob/c8/f/SOURCES/kernel-... for CONFIG_ARM64_64K_PAGES=y).

And AFAIK, to access the maximum amount of physical memory in AARCH64 (52-bit physical addresses, instead of 48 bit physical addresses), you must use 64k pages. Since RHEL is normally used on servers, it makes sense to want to be able to access huge amounts of physical memory; that's probably the true reason (or even the sole reason) RHEL uses 64k pages on AARCH64.

AMD64 supports only 48-bit addresses, and is still the most popular server ISA.

  You have: 2^48 byte
  You want: tebibyte
          2^48 byte = 256 tebibyte
          2^48 byte = (1 / 0.00390625) tebibyte

how many servers do you have with more than 256 TiB of RAM?

56-bit support was specced and had software support already in ~2016. 48 bits is not a hard architecture limitation. see eg https://www.kernel.org/doc/html/latest/x86/x86_64/5level-pag...

It's not only ram that goes in that 256 TB, memory mapped i/o uses it too. You probably don't have TB of video card RAM, but maybe some flash devices offer the whole thing memory mapped?

Good points. Re the last one: you of course also save some by having fewer pages and their metadata. Wonder what the space-optimal page size would be taking these opposing factors into account.

I bet this would also screw masses of user code making assumptions about optimal size, or simply designed/optimized for a smaller size. LMDB was the first thing that came to mind

Reply on news.ycombinator.com