zlacker

[parent] [thread] 10 comments
1. kloone+(OP)[view] [source] 2023-03-20 18:54:16
16k pages is going to make everything hard, I'm not holding my breath.
replies(2): >>sophac+a2 >>nicobu+NH
2. sophac+a2[view] [source] 2023-03-20 19:02:34
>>kloone+(OP)
What role does page size play here, and why is 16K a problem?
replies(3): >>gavins+Ul >>london+Qm >>jraph+SJ
◧◩
3. gavins+Ul[view] [source] [discussion] 2023-03-20 20:22:36
>>sophac+a2
The page size dictates the minimum size and alignment requirements for `mmap`, and also for regions of memory with different levels of protection (e.g. read-only vs read+write vs read+execute, etc). If a program expects to be able to `mmap` in 4kb chunks and can't, it will probably not work properly.

On macOS, IIRC the userspace and kernel-space page size can be different and different userspace programs can run with diferent page sizes, however on Linux the page size is currently fixed across the system and set at compile time. The M1's IOMMU only supports 16k-aligned pages, so memory regions that need to be shared with other hardware (e.g. the GPU) need to be 16k-aligned. As such (and because Linux doesn't currently have great support for mixed page sizes), the Asahi Linux project has decided to run with 16k pages globally. However, that breaks a number of applications that are expecting 4k pages.

More info: https://github.com/AsahiLinux/docs/wiki/Broken-Software

replies(1): >>pxc+8g1
◧◩
4. london+Qm[view] [source] [discussion] 2023-03-20 20:25:37
>>sophac+a2
Pages have been 4k on a lot of systems for 30+ years.

That means a lot of software has come to assume that.

Certain memory buffers need to be page size aligned, or a multiple of pages long. Code can only be loaded to a page aligned memory address. Memory mapping and read/write/execute permissions can only be set on a per-page basis.

If all that stuff is hardcoded now, there will be lots of fixes necessary to make things work properly with a different page size.

And those fixes probably will need the software to be recompiled. And some software is only distributed in binary form, and getting someone to recompile it may be nearly impossible.

5. nicobu+NH[view] [source] 2023-03-20 22:05:18
>>kloone+(OP)
I think the Asahi project will release a 4k kernel version for those really need/want it at some point. As I understand there are no technical barriers, they're just delaying it to push more projects into supporting the 16k mode (which has better perf).
replies(1): >>sliken+2L7
◧◩
6. jraph+SJ[view] [source] [discussion] 2023-03-20 22:15:13
>>sophac+a2
Sibling comments said it all, though "The Quest for Netflix on Asahi Linux", posted on HN [1] as a very good, detailed explanation of this and is a nice read.

[1] https://news.ycombinator.com/item?id=35081510

◧◩◪
7. pxc+8g1[view] [source] [discussion] 2023-03-21 01:50:07
>>gavins+Ul
Damn. There's some really important software on that list: libvirt/QEMU/KVM, LVM, WINE
replies(1): >>worthl+os1
◧◩◪◨
8. worthl+os1[view] [source] [discussion] 2023-03-21 03:44:44
>>pxc+8g1
I imagine that there will be a lot of work to improve this over the coming years, not just because of asahi, but the cloud ARM systems that are being developed.

I think that Fedora may be leading the pack here, see https://danielpocock.com/power9-aarch64-64k-page-sizes/

◧◩
9. sliken+2L7[view] [source] [discussion] 2023-03-22 20:17:41
>>nicobu+NH
I believe 4k pages works with Asahi Linux today. However the CPU can do 4k and 16k pages, the GPU is 16k pages only. So you give up accelerated 3D to run 4k pages.
replies(1): >>nicobu+qT9
◧◩◪
10. nicobu+qT9[view] [source] [discussion] 2023-03-23 13:48:38
>>sliken+2L7
Looks like 4k support has just been added to the GPU driver https://twitter.com/LinaAsahi
replies(1): >>sliken+v6a
◧◩◪◨
11. sliken+v6a[view] [source] [discussion] 2023-03-23 14:41:04
>>nicobu+qT9
Nice, I was right ... up to yesterday. Now it's fixed. Things are moving quickly.
[go to top]