A Linux-on-M1 update [LWN.net]

The Asahi Linux project has posted an update and reality check on the status of Linux support for Apple's M1 hardware.

We are continuously upstreaming kernel features, and 6.2 notably adds device trees and basic boot support for M1 Pro/Max/Ultra machines. However, there is still a long road before upstream kernels are usable on laptops. There is no trackpad/keyboard support upstream yet.
While you can boot an upstream 6.2 kernel on desktops (M1 Mac Mini, M1 Max/Ultra Mac Studio) and do useful things with it, that is only the case for 16K page size kernel builds. No generic ARM64 distro ships 16K kernels today, to our knowledge.

to post comments

A Linux-on-M1 update

Posted Feb 27, 2023 18:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Sidenote: I _love_ that they switched from Twitter and I don't get the "LOGIN TO TWITTER" message after half a screen of scrolling.

Thank you!

A Linux-on-M1 update

Posted Feb 27, 2023 20:51 UTC (Mon) by proski (guest, #104) [Link] (7 responses)

Twitter removed that annoyance recently. Still, it's good that Asahi Linux has switched to a site more appropriate for free software announcements.

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 0:42 UTC (Tue) by dskoll (subscriber, #1630) [Link] (6 responses)

Pretty OT, but someone told be about nitter.net. In any Twitter URL, replace twitter.com with nitter.net and you can read the thread in peace without actually going to the twitter.com site.

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 2:17 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (3 responses)

How well is that working with the API restrictions that have been put into place? Or does it just scrape the HTML render?

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 5:32 UTC (Tue) by pabs (subscriber, #43278) [Link] (1 responses)

It still works quite well, although some instances get too many visits and get temporarily blocked, so you need to try another instance or reload or wait.

Twtitter (was A Linux-on-M1 update)

Posted Mar 2, 2023 19:25 UTC (Thu) by flussence (guest, #85566) [Link]

It's also pretty trivial to run a local instance, and probably a better fit. AFAIK it just uses the Twitter web frontend APIs directly and those have rate limits intended for a single user.

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 16:14 UTC (Tue) by qyliss (subscriber, #131684) [Link]

The latter.

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 5:36 UTC (Tue) by pabs (subscriber, #43278) [Link]

This WebExtension will automatically change all Twitter website visits to Nitter ones. Similarly for YouTube and other sites.

https://libredirect.github.io/

Twtitter (was A Linux-on-M1 update)

Posted Feb 28, 2023 22:35 UTC (Tue) by job (guest, #670) [Link]

Not just that, it's much more nicer looking, super fast, and actually works they way you would expect!

It's one of those golden nuggets that make the modern web usable.

A Linux-on-M1 update

Posted Feb 27, 2023 19:25 UTC (Mon) by mfuzzey (subscriber, #57966) [Link] (19 responses)

Is it just a question of distros needing to provide packaged kernels with 16k page size or are userspace packages likely to be affected too?

I know userspace can use sysconf to obtain the kernel page size but it wouldn't surprise me if some code just hardcodes 4k.

Though it sounds like the 16k page size is temporary and they are planning on supporting 4k in the future?

A Linux-on-M1 update

Posted Feb 27, 2023 19:47 UTC (Mon) by Shawnl (guest, #163686) [Link] (11 responses)

The toolchain defaults to padding executable ELF sections to 64kb to support all three page size options (4k, 16k, and 64k), and most software doesn't care about page size.

A Linux-on-M1 update

Posted Feb 27, 2023 19:54 UTC (Mon) by josh (subscriber, #17465) [Link] (6 responses)

Anything that does mmap would need to take some care to avoid hardcoding page size, and many applications that do mmap have hidden assumptions of 4k until the first time they're ported to an architecture with a different page size.

A Linux-on-M1 update

Posted Feb 27, 2023 20:12 UTC (Mon) by Paf (subscriber, #91811) [Link] (5 responses)

Can you give some examples? I've worked some with mmap using applications and I can't think of much where they have dependencies on page size (optimizations which are page size dependent, yes, but nothing that just wouldn't work), unless they're using mmap to control hardware or something.

A Linux-on-M1 update

Posted Feb 27, 2023 20:35 UTC (Mon) by ballombe (subscriber, #9523) [Link]

mprotect requires that the address is aligned on a page boundary.
mmap always returns an address that is aligned on a page boundary, so it can be passed to mprotect as is.
However if you want to mprotect only a subset of what mmap returned, you have to make sure
that subset is aligned on page boundary.

A Linux-on-M1 update

Posted Feb 27, 2023 20:43 UTC (Mon) by chris_se (subscriber, #99706) [Link] (2 responses)

> Can you give some examples? I've worked some with mmap using applications and I can't think of much where they have dependencies on page size

From the manpage:

> offset must be a multiple of the page size as returned by sysconf(_SC_PAGE_SIZE).

Also, if you use MAP_FIXED (or MAP_FIXED_NOREPLACE), you have

> addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions.

Furthermore, while this isn't relevant to this specific thread, but if you want to write portable code and also support Windows, it uses a page size of 4kiB of x86_64, but requires all virtual memory mappings to be aligned to 64kiB. (But don't hard-code those numbers, it's possible to query this at runtime.)

I've written quite a bit of code that makes use of mmap() (especially for shared memory IPC) and I made sure to always follow the best practices here and dynamically query the OS for the correct alignments when needed. But I've also stumbled upon a lot of other code on the internet that just hard-codes these values. (Or worse, tries to be clever, and uses per-arch/os #ifdefs instead of querying them at runtime.)

Now obviously not everyone uses offset/fixed addresses, and if you just want to map an entire file (or at least a region that starts at offset 0), you don't have to care about the page size, and you'll never need to query it. (Not even on Windows.) But as soon as your use case gets a bit more complicated, you'll need to take this into account.

A Linux-on-M1 update

Posted Feb 28, 2023 2:51 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

To my understanding, the main "sensible" use case of MAP_FIXED is to replace an existing mapping (that you presumably created without using MAP_FIXED) - indeed, the man page explicitly says that this is the "only safe use for MAP_FIXED." I would tend to assume that you don't have to check alignment in that case, because any reasonable mmap should* already be returning memory that is page-aligned anyway.

* Shockingly, POSIX doesn't say that the return value of mmap needs to be aligned at all, unlike malloc(3), so a conforming implementation could give you an odd address! But I would like to believe that no modern implementation is quite that ridiculous.

A Linux-on-M1 update

Posted Feb 28, 2023 7:11 UTC (Tue) by comex (subscriber, #71521) [Link]

There’s still the case where you make one big mapping and then modify smaller chunks of the mapping, either by overwriting them using mmap with MAP_FIXED, or by just mprotecting them.

For example, if you were mapping a stack, you might want the first page to be a guard page, so you’d either mprotect the first page to PROT_NONE, or start with a big PROT_NONE mapping and then re-mmap all but the first page using MAP_FIXED. Or if you wanted to make a fast circular buffer by mapping the same buffer twice in a row (so that chunks of the buffer that wrap around the end can still be treated as contiguous memory regions), you’d make a PROT_NONE mapping with twice the buffer size, then make two MAP_FIXED mmap calls for the first and second aliases; in that case you’d make sure the buffer size is a multiple of the page size. Both of these could fail if you used the wrong page size.

A Linux-on-M1 update

Posted Feb 28, 2023 10:48 UTC (Tue) by dottedmag (subscriber, #18590) [Link]

You can make a fast ring buffer by mmaping the same physical page at two consecutive virtual page addresses, so if application uses small ring buffers it has to know the pagesize (either by runtime-checking the page size, or by changing granularity of ring buffer sizes to the multiple of 64k).

Some games use this trick.

A Linux-on-M1 update

Posted Feb 28, 2023 20:50 UTC (Tue) by arnd (subscriber, #8866) [Link] (3 responses)

binutils just reverted that feature and now is back to linking 32-bit arm binaries with a default 4KB alignment. This means that any distro shipping a 16KB (or larger) page kernel loses the ability to run those binaries, even in qemu-user.

A Linux-on-M1 update

Posted Mar 3, 2023 19:56 UTC (Fri) by floppus (guest, #137245) [Link] (1 responses)

That's unfortunate.

Naive question #1: is it possible to re-link such a 4k binary for compatibility with 16k/64k systems, without recompiling?

Naive question #2: would it be possible for ld.so to work around this at runtime, by rounding offsets up/down to the nearest multiple of the page size?

(both, obviously, assuming the program itself doesn't have baked-in assumptions about the page size.)

A Linux-on-M1 update

Posted Mar 3, 2023 20:42 UTC (Fri) by arnd (subscriber, #8866) [Link]

I'm pretty sure neither way works without relinking from the original .o files.

A Linux-on-M1 update

Posted Mar 5, 2023 20:49 UTC (Sun) by jcm (subscriber, #18262) [Link]

What's 32-bit?

A Linux-on-M1 update

Posted Feb 28, 2023 9:05 UTC (Tue) by make (subscriber, #62794) [Link] (6 responses)

I tried running Debian on an Ampere Altra box, and when I compiled the first kernel, I decided to give 64 kB pages a try, because 4 kB is awfully small by today's standards, and reducing overhead sounds good.

Almost everything was fine, there were only two issues:

- emacs crashed on startup because Debian's package came with a pre-built memory dump (/usr/libexec/emacs/28.2/x86_64-linux-gnu/emacs.pdmp) with 4 kB pages. I could delete that dump and then emacs worked (but its "bootup" was very slow).

- a Btrfs that was created on a different box could not be mounted. Apparently, the Btrfs on-disk format varies depending on the kernel's page size, which I found rather surprising.

A Linux-on-M1 update

Posted Feb 28, 2023 16:41 UTC (Tue) by kevinoid (guest, #128850) [Link]

Your comment made me curious: It appears that BTRFS Subpage Support (for sector/block sizes smaller than the page size) was added in v5.15, although there are still some limitations (and it's still considered experimental?). However, there does not appear to be support for reading sector/block sizes larger than the page size. Since the mkfs default sector/block size is the system page size, BTRFS filesystems created on systems with large page sizes are not readable on systems with smaller page sizes unless a small size is explicitly chosen at creation.

A Linux-on-M1 update

Posted Feb 28, 2023 18:00 UTC (Tue) by smoogen (subscriber, #97) [Link]

I don't think btrfs is the only filesystem (or the only code) which have had problems with mounting from differing system page sizes. This tends to be a fundamental assumption in the same way endian is. You usually run into it the opposite way (trying to use a large page size on a smaller system) but the problem can show up the other way also. I think anything which maps memory to layout and back again can blow up when that assumption doesn't hold. [I remember this with certain binary database layouts where the endian was the same but the memory page size was different and so the databases could not be read from one to another Unix box.]

A Linux-on-M1 update

Posted Feb 28, 2023 19:55 UTC (Tue) by welinder (guest, #4699) [Link] (3 responses)

Emacs should probably seek alternatives to the restarting-a-core-dump method that is currently used. (That description is morally true, not literally.)

There were very good reason that this method 20 years ago, but not so much in this day and age.

A Linux-on-M1 update

Posted Feb 28, 2023 22:32 UTC (Tue) by geofft (subscriber, #59789) [Link] (2 responses)

Apparently the .pdmp file _is_ their answer for this day and age! Until version Emacs 26 (which is what Debian oldstable has), they used unexec, the thing that made sense 20 (or 30) years ago, and I think it just would have failed completely in this case because there's nothing to delete. Starting with Emacs 27 (which is what Debian stable has), there's a new and improved system. Quoting from emacs/etc/NEWS.27:

** Emacs now uses a "portable dumper" instead of unexec.
This improves compatibility with memory allocation on modern systems,
and in particular better supports the Address Space Layout
Randomization (ASLR) feature, a security technique used by most modern
operating systems.

When built with the portable dumping support (which is the default),
Emacs looks for the "emacs.pdmp" file, generated during the build, in
its data directory at startup, and loads the dumped state from there.
The new command-line argument '--dump-file=FILE' allows specifying a
non-default ".pdmp" file to load the state from; see the node
"(emacs) Initial Options" in the Emacs manual for more information.

An Emacs started via a dump file can create a new dump file only if it
was invoked with the '-batch' option.  (This is a temporary
limitation; we plan on lifting it in a future release.)

Although the portable dumper has been tested, it may have a bug on
unusual platforms.  If you require traditional unexec dumping you can
use the configure-time option '--with-dumping=unexec'; however, please
file a bug report describing the situation, as unexec dumping is
deprecated, and we plan on removing it in some future release.

But it's still the same conceptual model (at the end of the build process, start Emacs, load some Lisp, dump out process state, and ship that to users), probably they should do something entirely different, somehow.

A Linux-on-M1 update

Posted Mar 1, 2023 0:16 UTC (Wed) by welinder (guest, #4699) [Link]

Thanks -- much relieved. (I turn my back on Emacs details for a decade or two and suddenly find myself out of date. Sheesh!)

A Linux-on-M1 update

Posted Mar 1, 2023 15:59 UTC (Wed) by nix (subscriber, #2304) [Link]

Lisp systems have worked this way since time immemorial: it's hard to twist your brain to think differently about it if you've been thinking this way for fifty years.

A Linux-on-M1 update

Posted Feb 28, 2023 16:46 UTC (Tue) by eduperez (guest, #11232) [Link]

"Never let the truth get in the way of a good story"