Reminder that if you get jemalloc errors on software...

Reminder that if you get jemalloc errors on software running on Asahi, that's because the jemalloc maintainers refuse to make jemalloc builds portable to all ARM64 systems by default.

Some downstream projects also refuse to override the default for their builds when the issue is raised with them, like Telegram Desktop.

Unfortunately, choices like these are sabotaging the ARM64 Linux ecosystem by explicitly making binaries non-portable, and if people don't listen to our feedback, there is very little we can do to help. These "build for the host page size" approaches are as non-portable as -march=native, but people seem to think it's okay when you're breaking ARM64 systems and not x86_64 systems for some reason.

Like 1 11 November at 10:16 | Open on social.treehouse.systems

11 comments

Hector Martin

To be clear, it's perfectly okay to allow non-portable builds for people who want to rice out their system a la Gentoo. That seems to be the motivation for the jemalloc behavior in the first place.

But the default should always be portability. Always.

11 November at 10:23 | Open on social.treehouse.systems

翠星石

@marcan >Not compiling everything from source.
ngmi.

11 November at 10:23 | Open on freesoftwareextremist.com

Zergling_man

@marcan When you build the source code yourself, you build it for your architecture, and then it automatically works there. But when someone else builds it for you, he has to,
1. know that your architecture exists; and
2. give a shit about you; and
3. find a computer like yours to test it

Usually one of these criteria is not met (guess which one).

- https://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml

Expand text...

11 November at 10:26 | Open on sacred.harpy.faith

Rahul Vadhyar

@marcan Can the broken applications be run in the microVM that steam uses, since that is built for 4K pages as a workaround?

11 November at 10:33 | Open on social.treehouse.systems

Hector Martin

@RahulVadhyar Yes, but that's immensely silly for FOSS software, and it comes with downsides. We do not advocate nor support using the VM solution as a workaround for poor FOSS software packaging, the problem needs to be fixed at the source. The VM is for proprietary x86_64 software run under emulation.

11 November at 10:34 | Open on social.treehouse.systems

Fabio Valentini

@marcan *sigh*

this is one of the reasons why we rip out jemalloc custom allocators from all Rust packages in Fedora. looks like in most cases the upstream projects only chose jemalloc because "it's supposed to be faster but I didn't actually have meaningful benchmarks for that" anyway ...

11 November at 10:53 | Open on mastodon.social

mittorn

@marcan Dynamic 4k/16k pages support may affect performance, so it seems, jemalloc just need dynamic switch between two implementations (ifunc may be useful)

11 November at 11:02 | Open on masturbated.one

Marcin Juszkiewicz

@mittorn @marcan

It is 4/16/64k pages. There are users (like HPC) which go 64k for some % of performance.

11 November at 11:37 | Open on society.oftrolls.com

mittorn

@hrw @marcan anyway it may be implemented by reading page size in ifunc and placing correct functions during dl relocation

11 November at 11:38 | Open on masturbated.one

C.S.Strowbridge

@marcan

This showed up in my Explore feed and this post could be a parody and I would never know it.

11 November at 11:15 | Open on mastodon.social

Vlastimil Babka

@marcan thanks for another reminder that you love to use your large social media following to incite dogpiling. Your comment on that github issue was even called out as abusive: https://github.com/jemalloc/jemalloc/issues/467#issuecomment-2307656698
Still no self-reflection on your side? Too bad.

11 November at 11:32 | Open on social.kernel.org