Software > Operating Systems and Porting
kernel config: page size 4k vs 64k
pocock:
Most distributions have chosen the 4k page size for their kernels on Intel architectures.
On powerpc64le, Debian (since 2014) and Fedora are using 64k
This may be good for HPC environments but troublesome for workstation users
Here are some specific observations:
Nouveau driver apparaently won't work at all on anything other than 4k
btrfs filesystems have a sectorsize that corresponds to the page size on the host where the filesystem was created. The filesystems can't be mounted on any host with a different page size.
Example problems:
* you have a 6TB drive with btrfs from an x86 workstation, you want to move it to a Blackbird running the default Debian or Fedora kernel but it won't mount.
* you install Fedora 33 with the default kernel (64k page size) and default filesystem (btrfs from Fedora 33) and later you want to recompile your kernel for 4k. Now you can't mount your root filesystem because mkfs was run for 64k
As Fedora is going to use btrfs by default now, btrfs volumes will be more common and users are more likely to encounter frustration from time to time.
The btrfs developers recently started a patch that allows the systems with 64k page size to read a btrfs volume with 4k sectorsize. It only works in one direction and it is read-only.
Does anybody feel that distributions should offer different permutations of their kernel and installer based on the 4k page size?
From the perspective of workstation users, are there any other strong reasons, other than Nouveau and btrfs, for distributions to consider this?
ClassicHasClass:
Some emulation and virtualization tools have dependencies on page size. We had some page size issues in Firefox initially, though I think we smoked most of those out.
I'd certainly prefer a 4K page size as it's more "typical" but given RHEL's prominence on HPC POWER I can understand why Fedora ppc64le defaults to 64K as well. I certainly wouldn't expect them to do two flavours, especially since they don't even support big-endian ppc64 anymore, which I think would be more significant architecturally than page size.
FlyingBlackbird:
--- Quote from: pocock on September 14, 2020, 05:19:55 am ---Most distributions have chosen the 4k page size for their kernels on Intel architectures.
The btrfs developers recently started a patch that allows the systems with 64k page size to read a btrfs volume with 4k sectorsize. It only works in one direction and it is read-only.
--- End quote ---
You are mentioning the kernel "memory" page size (`getconf PAGESIZE") and the `btrfs` file system page size.
Just to understand this issue right:
How is this related? Does `btrfs` by default (or always?) use the same file system page size as the kernel does for the memory page size?
pocock:
Yes, that is correct, the sectorsize parameter for a btrfs filesystem must be the same as PAGESIZE for the kernel
Therefore, btrfs filesystems created on systems with a 4k page size can only be used on systems with a 4k page size
btrfs filesystems created on systems with a 64k page size can only be used on systems with a 64k page size
pocock:
--- Quote from: ClassicHasClass on September 14, 2020, 08:47:48 pm ---Some emulation and virtualization tools have dependencies on page size. We had some page size issues in Firefox initially, though I think we smoked most of those out.
--- End quote ---
Maybe that is why Thunderbird is not working at all either.
Simply running a 4k kernel doesn't always fix the issues. Sometimes it is necessary to rebuild each broken application on the host running a 4k kernel. This is because the build scripts of some applications look at the page size during compile time and assume it will be the same for run-time and they hardcode it into the binary.
I will probably try building both the Firefox and Thunderbird packages from source on a Debian buster host running with the 4k page size.
I tried Firefox for a WebRTC call yesterday and the video was missing, I'll see if that works with the 4k page size too, with and without recompiling Firefox itself.
The two biggest concerns I heard from people about this platform are not being able to use Firefox reliably and the noise issues. Developers are reluctant to embrace any platform that might sidetrack us from the things we are supposed to be working on. If the noise issues can be fixed with Vikings' water cooling solution and the Firefox issues can be reined in by a 4k page size then it could make a crucial difference to the success of the platform. It is therefore quite important to look at how to engage distributions in that solution.
Navigation
[0] Message Index
[#] Next page
Go to full version