Latest nightly binary is broken on aarch64 Asahi ("unsupported system page size")

[eggyal]

On aarch64 GNU/Linux:

$ rustc +nightly -vV
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
LLVM ERROR: out of memory
Allocation failed
Aborted (core dumped)

searched nightlies: from nightly-2024-12-19 to nightly-2024-12-20
regressed nightly: nightly-2024-12-20
searched commit range: 4ba4ac6...9e136a3
regressed commit: 023521e

bisected with cargo-bisect-rustc v0.6.7

Host triple: aarch64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --without-cargo --start 2024-12-19 --script ./check.sh 

Due to #133809 cc @mrkajetanp @Kobzol
@rustbot label +I-compilemem +O-AArch64 +requires-nightly +S-has-bisection

[ionicmc-rs]

Hey it didnt add the labels, let me try to add them

@rustbot label I-compilemem O-AArch64 requires-nightly S-has-bisection

[Kobzol]

Thanks for the report. We should probably first get the after-dist tests running, or make sure that we test and deploy aarch64 on the same hardware, because currently we don't really have any tests that check whether the built artifacts actually work..

Posted a revert in #134564.

[bjorn3]

Are you on Asahi Linux by any chance? Asahi Linux uses 16k pages, but Jemalloc only supports a page size of at most the page size of the build system unless you explicitly override it with --with-lg-page at compile time. The tikv-jemalloc-sys crate we use supports setting this using JEMALLOC_SYS_WITH_LG_PAGE at build time.

[eggyal]

Yes, I can confirm this was on Asahi.

[Kobzol]

Ok, so something like this wouldn't be caught on our CI anyway then. But it still seems like a regression, so we should probably restore the original behavior.

[mrkajetanp]

Should we maybe then just switch off jemalloc for this build since that's where the problem seems to be?

[Kobzol]

jemalloc should provide a non-trivial performance improvement, so it seems like a shame to disable it (since the goal of this effort was to improve rust'c performance on aarch64 :) ). So I'd probably first try restoring the current behavior, by allowing jemalloc to work with larger page sizes.

[ionicmc-rs]

Are you on Asahi Linux by any chance? Asahi Linux uses 16k pages, but Jemalloc only supports a page size of at most the page size of the build system unless you explicitly override it with --with-lg-page at compile time. The tikv-jemalloc-sys crate we use supports setting this using JEMALLOC_SYS_WITH_LG_PAGE at build time.

I guess this would be triage (correct me if im wrong)

@rustbot -needs-triage

[mrkajetanp]

So I'd probably first try restoring the current behavior, by allowing jemalloc to work with larger page sizes.

For sure, that's the proper solution. FWIW this is a wider issue than just this PR, e.g.:

#133748

[mrkajetanp]

So we can revert it for now as a stop gap but the underlying issue still needs to be fixed with the aforementioned JEMALLOC_SYS_WITH_LG_PAGE.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical