I've been using the lqx kernel on my old Zenbook for a while now and it's made a huge difference in usability, so a huge thank you for this project! Can the lqx patches benefit an ARM system in any way? If not all of it then what pieces might pose some benefit? Specifically for me it would be the Pinephone - I've been tinkering and looking for ways to reduce latency.
Back to top

There's a lot of reasons I may never make a kernel for any ARM systems.

1. Performant ARM systems typically follow the big.LITTLE CPU architecture. PDS doesn't have proper compatibility to schedule tasks correctly on the right cores. Maybe a user space daemon will arrive that does that for us so the kernel doesn't have to worry.

2. Performant ARM systems typically also need an optimized kernel for each one. This is very evident in the Android phone market, it makes it unfeasible to make "good" generic kernels that "just work". You can see here just from LineageOS that they have to maintain ancient kernels for older Qualcomm SoCS: lineageos.org/Changelog-27/. A lot of it is all the binary blobs required to activate all features of the SoC.

3. Non performant ARM systems, like PinePhone and PineBooks, are not performant enough for daily use. I bought my own PineBook Pro and attempted to tweak the Manjaro kernel to get better performance, but the GPU is underpowered and the Mesa situation is awful. Maybe one day it will get better but we're probably 5 years away. My PineBook Pro was sold to a friend who was more interested than me, so I don't have the hardware anymore to maintain and test. Here's the github repo I was experimenting with if you want to see: github.com/damentz/linux-lowlatency-aarch64. None of the changes I made mattered because the PineBook Pro couldn't even render a KDE desktop at 1080p at 60fps in the first place.

4. Kernel development will be costly since I'll need to use cloud resources to build and test efficiently. I'm already imagining a small ephemeral cluster in AWS using Graviton instances, not excited to pay that bill. Just for reference, it takes a 5950x about 6 minutes to build a kernel for Liquorix today. It took a PineBook Pro over 120 minutes, or 2 hours. Having a powerful local ARM system is important for fast feedback when testing and working through build failures.

There's some other reasons. Personally I'm just not ready to dedicate all that time to a device I won't use when there's superior alternatives with x86 at the moment.
Back to top

Thanks for answering so thoroughly. The juice doesn't seem to be worth the squeeze, though I am wondering if the same fragmentation problems with the optimized kernels would apply to RISC-V SoCs. Not that there are an abundance of options to work with there.

From my experience with the Pinephone I'm guessing that the Pinephone Pro might be just barely enough power for a tolerable experience. To say that the PP is underpowered is a serious understatement. I'm in the rather unenviable position of needing it to be my daily driver atm, hence my question.

lowlatency-aarch64 link appears to be broken.
Back to top

I wonder, since Intel has adopted big.LITTLE after Alder Lake, would PDS work worse than CFS on Alder Lake or later Intel CPUs?
Back to top

Just to add to damentz' answer, as I understand it, these SOC ARM devices require a specific device tree for each device, which is I believe part of the kernel. This makes it a royal PITA to maintain kernels for these devices.

Hopefully this has improved at least slightly since I last really dived into the ARM SOC world.

Note most of the SOCs don't have DMI tables, so all the hardware almost is discovered by the device tree, which is specific to each device, though I think maybe there's a slightly more generic form, not sure, but I think there is, or maybe they compile several device trees into one kernel, I don't know.

This is for example what Raspbian did, and it's also by the way why BSDs have had and continue to have a lot of issues supporting SOC ARM devices, sometimes they will crudely boot, but performance will be so utterly dismal you'd never want to go beyond that. We tried, and gave up, for inxi ARM BSD support.

Really you want to leave SOC ARM support for projects who have the hardware to test on, who care, and are into it.

Manjaro used to have a pretty good ARM group, but I don't know where that's at now. Armbian I think was a sort of relatively general purpose debian based ARM os.

But supporting ARM is really different from supporting more standard pci type hardware, mainly because of the total failure to make any kind of pci/dmi/usb like hardware discovery method that most pc hardware benefits from, which is I think roughly why linux tends to boot on a lot of hardware, though sometimes you need newer kernels to get the specific drivers for specific components, like amdgpu for newer APUs from AMD, or newest intel for newest intel gpus.

If I were damentz, which I'm not, I'd toss the ball back to anyone who is interested, because you really have to be interested, you have to own the hardware, you have to get all the new versions of the hardware you are trying to support, it's basically endless.

You'd think that by the 2010s or so, the computing world would have learned the value of creating simple reliable hardware standards to make it easier on everyone when it comes to relatively new platforms, but nope, it didn't happen. I think part of the code required to even run a lot of SOCs is not BSD license compatible either, and since they are all designed to run linux first, there's no real way for the BSDs to get good support, if any support at all.

Stuff like this can be an interesting albeit very very time consuming project, and the best way really to do it is to do it, that's how the stuff happens, and if it's not done, it's not done, and that's also fine since other people are doing it.

But you have to think device by device, it's really not very pleasant, it's a big reason why phones are almost impossible to support generally by linux for example, and why you can't really upgrade android when support stops, the drivers aren't open source often, or are not in mainline kernel.

But a wise person walks away from ARM SOCs unless they love them and really like playing with them, and plan to keep liking it for at least 5 to 10 years into the future, which is the real timeline for a project that doesn't fade and vanish in a few months.

Note that there are also servers with real systems, pcie, dmi, pci, etc, I was going to get a look into one of those to check what inxi needed to add, but I never really got the data so I have not seen a real arm server yet, which is not a SOC, it's a CPU that is ARM.

Other variants that have made it even worse is the new M1/M2 all in one that takes SOC to a whole new leval, adding in the RAM, the GPU, the various bridges, into one megachip, which is why it's so hard to add quality linux support for those cpus / socs.
Back to top