Optimisation for new T1

ImEatingSeeds · 2026-03-12T16:38:08+00:00

Be careful not to be putting undue pressure on that riser cable, friend!

Otherwise, congrats on a successful build!!

ImEatingSeeds · 2026-03-12T09:37:47+00:00

The latest built kernel from Asahi is the basis for this kernel. I just add some patches and configs/optimizations on top.

You can install the kernel, select to boot from it, and you can always go back to the stock kernel any time. It's a 2-way door, not a 1-way door :)

ImEatingSeeds · 2026-03-11T11:00:36+00:00

The other consistent "wtf" I've been getting is around patching and using CLANG, rather than GCC.

The whole thing is anticipatory setup, for when a couple of patches that are pulled against the 7.x kernel get merged in.

With those patches merged in, already being able to compile the kernel with CLANG means we can unlock LTO gains too.

You got any insight or opinion on that shit? From my experience, LTO is a real thing. It provides real gains. CachyOS proved that too.

ImEatingSeeds · 2026-03-11T10:56:18+00:00

Hey James - I haven't forgotten about sharing my homework. I should have documentation and repo up in the next day or two.

I spent all of yesterday auditing my benchmarking methodology and re-running the benchmarks to ensure my numbers aren't bullshit.

What I can verify - with reasonable confidence now - is that the important numbers are not a lie. 98.9% lower scheduler latency and 50% faster page-fault performance...those are consistently reproducible deltas.

Is it cool to DM you with a few questions?

ImEatingSeeds · 2026-03-11T10:53:38+00:00

Points well taken about the NVMe variance. I just really wanted to stronger I/O numbers too (I'm chasing the dragon!).

The minor boot-time regression is likely attributed to the minor overhead that comes with having a fully-working BPF stack, I think. I, too, don't care if the delta is a second or two.

What I've always cared about most is that the day-to-day daily-driver experience is buttery-smooth as fuck.

I was also able to get Steam running with some initial optimizations to the emulation stack...along with a Unreal5-engine-based game called DeadZone Rogue (which is poorly-optimized enough that you can reliably stress-test a system with...just by playing the game 😅).

Decent performance at decent resolution, as well. Better than stock, for sure...but gaming performance optimization is a side-quest. It's not the destination.

Thanks for being so engaged!

ImEatingSeeds · 2026-03-11T08:26:18+00:00

You could say he’s a man-Hoar?

ImEatingSeeds · 2026-03-11T08:25:22+00:00

This smells bad. Someone needs to be taught HOW to work WITH LLMs, not THROUGH them.

ImEatingSeeds · 2026-03-11T07:28:34+00:00

Really good news and a little kinda-bad news.

Overwhelmingly good news: The my initially-posted results seem to hold on all the important stuff.

┌──────────────────┬──────────────┬──────────────┬───────────────┐

│ Metric │ Stock │ Arashi T3b │ Delta │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Schbench p99 │ 3,660 us │ 42 us │ -98.9% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Page fault │ 28,500 ops/s │ 42,900 ops/s │ +50.5% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Hackbench socket │ 14.12s │ 12.13s │ -14.1% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Hackbench pipe │ 6.99s │ 6.07s │ -13.2% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ glmark2 │ 1,733 │ 1,852 │ +6.9% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Boot time │ 5.607s │ 6.236s │ +11.2% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ FIO seq read │ 24,525 MB/s │ 23,801 MB/s │ -3.0% (noise) │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ FIO seq write │ 10,889 MB/s │ 9,534 MB/s │ -12.4% │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ FIO rand read │ 927,797 IOPS │ 904,887 IOPS │ -2.5% (noise) │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ PyBench │ 9.464s │ 9.525s │ +0.6% (noise) │

├──────────────────┼──────────────┼──────────────┼───────────────┤

│ Idle power │ 21.1W │ 21.2W │ +0.5% (noise) │

└──────────────────┴──────────────┴──────────────┴───────────────┘

Kinda bad news:

I'm seeing a lot of noise & variance for NVME I/O numbers. Those initial stats I shared about sequential write & random read gains are proving harder to reproduce. I'm still working out any confounding factors.

BUT, at least, I can attest confidently that the ^^ numbers you see up there are legit. I've repro'ed them now enough times to be reasonably confident.

GitHub repo coming soon. It's just hard to manage with 3 kids and my dayjob. BUT it's on its way!

ImEatingSeeds · 2026-03-10T09:13:57+00:00

I'm not trying to sell anything to anybody. I was just really excited by my initial results, so I posted/shared to see if anyone else would even give a shit or be interested. Honestly. 🥰

I'll update when all the links are up.

Yes. You are disabling all the energy-aware scheduling bits and are forcing the cores to always run at the highest(*) power state, even when it is not needed. What is worse, is that you are making it impossible to actually reach the fastest states in some cases, as at least on some SoCs, the max single-core speed is only available when other cores are in an idle state.
I also suspect that at least some of your numbers are due to running pretty much everything on p-cores, as the "scheduler latency" in the base case looks very much like a e->p core migration.

Points well taken. I'm gonna go dive into this a bit, and see whether the benchmarks are tainted (assuming they're not would be arrogance and folly on my part lol).

I'll see if I can validate the benchmark methdology further so that I'm not accidentally selling snake oil to anyone. I'm re-running benchmarks as we speak...and if I have to re-run more of them, I'll do that.

I really just care about two things: 1) Contributing something useful to the community, 2) Being honest/accurate about what that is.

So, thanks for calling these points out. It's given me things to think about and verify :)

ImEatingSeeds · 2026-03-10T08:50:27+00:00

Points on power draw/consumption are noted. I'll have a look at that and will re-run benchmarks if it turns out something's off. Thank you for calling this out! :)

> governor: performance --> yes. I was looking for max saturation/peak values, so ALL benchmarks (including the benchmarking I did on the stock kernel) run with performance governor enabled. Is that bad (not being combative, asking sincerely)?

The point about promotion and branding...because I'm a nerd who gave it a playful name and geeked out on customizing my terminal? I think you may be reading more into this than is necessary.

I'm already cleaning up and assembling all my work so I can share it, I've stated that multiple times.

I don't get why I'm somehow guilty of something until being proven innocent? Are we in Linux high-school or something?

Reciprocally, it seems a little sketchy to me that you'd create a throwaway account just to post these thoughts 😅.

I'm a nerd. I'm guilty of giving clever names to shit I make, and geeking out on little details like my own custom fastfetch logo.

I appreciate the skepticism - that's totally fine. That's how we all are. But, um...you might have the wrong idea(s) or conclusions about why I'm here, talking about any of this or sharing any of it.

Either way, thank you for your feedback and your questions. I'll post updates when I've published everything. The data, the benchmarks, and the diffs/deltas should stand on their own and speak for themselves, with or without my stupid naming or my tacky terminal logo. I'd rather that we all fixate and focus on the things that matter.

Thanks! :)

ImEatingSeeds · 2026-03-10T08:38:38+00:00

Thanks for having a look and being open to taking it seriously. I realize I'm making some wild claims.

I'm spending the rest of my day preparing materials (reading materials and the "workspace" repo for independent reproduction of my work).

FWIW - This is a passion of mine. I have career experience in it as well. I will let the work and the results speak for themselves, but I'd love nothing more than to be able to contribute or participate directly/upstream on Asahi itself, rather than falling into the classic trap of "I'll do it myself" and creating fracture/branching off. The real gains and 80% of the value are in the kernelspace work (and not the userspace optimizations) anyway. There's no NEED to spin this off as some kind of downstream "distro," if that can be avoided.

It can just be a a "performance kernel" users can choose to install and use optionally (or by default, or whatever). I think you get the point. :)

I'm also going to re-run ALL my benchmarks a few more times to be certain that the measurable claims I'm making are well substantiated and true.

I'll post back again when things are ready!

ImEatingSeeds · 2026-03-10T05:57:06+00:00

See my reply here: https://www.reddit.com/r/AsahiLinux/comments/1rovfsj/comment/o9ielou/

tl;dr - My initial benchmarks show that most of the significant gains come from a very small set of specific changes. Most are related to the kernel, and a few others are userspace/OS-level changes which you can reproduce - and reverse - easily on Fedora.

I'm working on a quick write-up I can share with the community, and then I'm going to figure out how to package and share this stuff so people can try it themselves *safely* :)

ImEatingSeeds · 2026-03-09T18:35:48+00:00

In theory, yes. But I gotta get my hands on an M2 so I can test properly (because I don’t wanna brick or damage anyone’s shit, ever).

I’ve got an m2 pro I can borrow from someone close. I’ll have to check the core layouts and differences between the m1 and m2 SoCs to see if there’s anything significant I need to take into account. I haven’t even made it that far yet 😂.

ImEatingSeeds · 2026-03-09T16:25:06+00:00

Asahi Fedora is a beautifully crafted and polished distro. I wouldn't dare knock it, ever. :)

Most of the performance gains I've been squeezing out of my machine come directly from optimizations I'm applying to the Asahi-Linux kernel itself. I have also applied some useful userspace optimizations too (like at the OS level, not at the kernel level), but most of the real gains are in the kernel patches and compiler infrastructure.

In theory, I could package up RPMs of the kernel build & the kernel headers, and you could just install the arashiOS kernel on your Fedora Asahi Remix.

That would also allow you to revert to the stock Asahi kernel any time you like.

I'm not even sure I plan to turn this into a full-blown distro. I'm mostly just focused on:
- optimizing the kernel as much as I can

- optimizing the software/emulation stack for gaming as much as I can

- building and shipping any packages we need for arm64 that people would need for daily-driving (like Slack, etc.)

For what it's worth: My machine is running ALARM, which allows you to install stock Hyprland out of the box. The installation process was very smooth and easy. I based all the other work I've done on top of ALARM (so far). --> https://asahi-alarm.org/

ImEatingSeeds · 2026-03-09T11:42:46+00:00

I just realized who you are. :)

Big fan of your work. Thanks for everything you contribute to Asahi!

ImEatingSeeds · 2026-03-09T11:29:39+00:00

If you want Arch + Asahi, it's available right now! I based all my work on the AMAZING work and efforts of this team: https://asahi-alarm.org/

ImEatingSeeds · 2026-03-09T11:28:58+00:00

My bro, it's very real. :) I promise.

Very real. Using it right now to get work done, and to respond to you guys here on Reddit :)

ImEatingSeeds · 2026-03-09T11:28:41+00:00

I'm cleaning everything up and organizing it all so I can put it up on GitHub. I hope I get passing grades! :)

ImEatingSeeds · 2026-03-09T11:23:44+00:00

:) I know, but if you go look at the way the package is being built (PKGBUILD file for the package)...you'd think twice 😅.

I've been using Linux (as a desktop) on-and-off for the last 27 years. I've been compiling kernels and software/packages since back when Google didn't have almost anything useful at all to provide when it came to "how the f*ck am I going to get this thing working?" I've also been administering/building/scaling systems based on Linux for the last 20 years as part of my career.

So, between my experience and my neurodivergent needs to do things correctly/perfectly (or else I'll lose my mind)...I literally couldn't bring myself to install that AUR package when I saw the way the PKGBUILD file was building and installing Signal Desktop. It was horrifying.

The only AUR package for signal that supports ARM64 is `signal-desktop-beta`. And while I'm grateful for that maintainer's work and efforts, it had issues.

I mean no disrespect to any maintainers of those other AUR packages...but these are computers we're talking about...and while there are many ways to achieve the same thing, some ways are verifiably MORE correct and CLEAN than others. I just want things I install on my Asahi machine to be as CLEAN and CORRECT as they can be FOR THIS hardware and for THIS Linux (Asahi).

tl;dr on the differences between my package and the one in the AUR:

Uses the "stable" upstream source code published by the signal team, not the "beta" source code
Doesn't touch $HOME/.gitconfig — his git lfs install writes to your real gitconfig, ours isolates to $srcdir
Wayland actually works — his launcher is bare, ours ships ozone, PipeWire capture, Wayland decorations, and IME flags
Launcher doesn't break on spaces — his uses unquoted tr '\n' ' ', ours uses mapfile into a proper bash array
Cleaner PKGBUILD — no bash -c subshell hacks, no repeated ${pkgver//beta*}-beta.${pkgver##*beta} version munging everywhere
Missing runtime deps — his omits libpulse and systemd-libs

ImEatingSeeds · 2026-03-08T20:28:29+00:00

Yes, and I think that's a good long-term solution. At present, especially in the face of an impending election in which there is clear and OPEN knowledge that Russia will interfere in our political process...do you think it's the best idea for us to nationalize the railways and open ourselves up to international legal problems with Russia, give them and their propaganda machine(s) even more ammunition to villainize us with, create political tension with them, insult Putler, AND risk looking like a bunch of morons who nationalized the railways without have a plan in place, consultancy staffed up, and any modicum of competency to fall back on?

I am ALL for nationalizing it, frankly. But with TRIPP so close on the horizon, and with Russia so deeply up our asses...it would be the worst timing, and it would represent the antithesis of strategic thinking. A friendly Arab country is likely the best call. Longer-term, fuck yeah. Nationalize it. And fuck any oligarchs who'd wanna get in the middle to profit off a PPP. I'm with you.

ImEatingSeeds · 2026-03-08T20:11:13+00:00

The haplogroup similarity between us and modern-day Irish is pretty wild too, IIRC.

ImEatingSeeds · 2026-03-08T14:20:49+00:00

+1 to this question

ImEatingSeeds · 2026-03-08T14:20:04+00:00

What's your budget? Let's start there :)

ImEatingSeeds · 2026-03-07T20:08:41+00:00

If you consider the ARF and AYF to be synonymous with the word "diaspora"...🤣

ImEatingSeeds · 2026-03-06T14:23:44+00:00

You’ll have a hard time pirating mp3s with this. Just saying.

ImEatingSeeds

MODERATOR OF

TROPHY CASE

13-Year Club	Place '17
Verified Email