4 ms·

The 16k page size might be temporary in this port, the HW does support 4k pages as well. In an earlier post they said this about progress on the iommu hw limit

The 16k page size might be temporary in this port, the HW does support 4k pages as well. In an earlier post they said this about progress on the iommu hw limitation leading to start out with 16k page size: "Sven took on the challenge and now has a patch series that makes Linux’s IOMMU support layer play nicely with hardware that has an IOMMU page size larger than the kernel page size" (https://asahilinux.org/2021/10/progress-report-september-2021/ https://asahilinux.org/2021/10/progress-report-september-202...)

WhyNotHugo 5y ago
Apparently 16k pages result in a huge performance boost (20%) for many workloads, so hopefully broken software will adapt too.
- fulafel 5y ago
  Isn't it more about not breaking binary compatibility with existing Linux arm64 userland that has been stable for many years, than source level correctness bugs in apps? Or does the userspace ABI explicitly allow for switching between 4k and 16k page size? (Also apps can always opt-in to bigger pages using the existing mechanisms) Of course it's also true that 4k is a ridiculously small page size, we've been using the same size for 30-40 years while memory sizes have grown 5-6 decimal orders of magnitude. But from that POV we should now do a bigger bump than 4k->16k - I think the next bigger commonly used page size on ARM Linux has been 64k.
  - lonjil 5y ago
    Page size is not set when you compile. At runtime, you can ask the kernel what the page size is, and use that value where appropriate. Some poorly written software hardcodes the page size on a per target basis.
    - fulafel 5y ago
      I know there are some Unix specs that say that page size is reported via runtime interfaces, but I suspect that eg on x86 if you built a Linux kernel that gave userspace a 2MB page size, and started returning that from the sysconf(_SC_PAGESIZE) interface, many (most?) apps would break and shrugging that away with "those apps are just broken" would be a nonstarter. But maybe just counts as a a de facto user expectation and is not documented anywhere architecture in Linux ABIs?

WhyNotHugo 5y ago

Apparently 16k pages result in a huge performance boost (20%) for many workloads, so hopefully broken software will adapt too.

fulafel 5y ago
Isn't it more about not breaking binary compatibility with existing Linux arm64 userland that has been stable for many years, than source level correctness bugs in apps? Or does the userspace ABI explicitly allow for switching between 4k and 16k page size? (Also apps can always opt-in to bigger pages using the existing mechanisms) Of course it's also true that 4k is a ridiculously small page size, we've been using the same size for 30-40 years while memory sizes have grown 5-6 decimal orders of magnitude. But from that POV we should now do a bigger bump than 4k->16k - I think the next bigger commonly used page size on ARM Linux has been 64k.
- lonjil 5y ago
  Page size is not set when you compile. At runtime, you can ask the kernel what the page size is, and use that value where appropriate. Some poorly written software hardcodes the page size on a per target basis.
  - fulafel 5y ago
    I know there are some Unix specs that say that page size is reported via runtime interfaces, but I suspect that eg on x86 if you built a Linux kernel that gave userspace a 2MB page size, and started returning that from the sysconf(_SC_PAGESIZE) interface, many (most?) apps would break and shrugging that away with "those apps are just broken" would be a nonstarter. But maybe just counts as a a de facto user expectation and is not documented anywhere architecture in Linux ABIs?