I'm currently running Debian 10 (Buster) with 5.2.0-5.1-liquorix-amd64. My DE/WM varies at my whim, but is currently Budgie. The machine in question is:

Asus RoG Maximus X Hero Z370
Delid Intel Core i7 8700k (running 5GHz all cores and cache @ 1.3v)
32GB TeamGroup 8Pack Edition DDR4 3600 (running 4333MHz cl19 @ 1.45v)
Samsung Evo 970 nVME SSD
Sapphire Pulse Radeon Vega 56

I normally use Chromium with VAAPI to play video, to offload playback to my graphics card. I do prefer Firefox though, for privacy reasons. I noticed that on the default Debian kernel Firefox uses around 12% to 15% total CPU when playing back 1080p x264 videos. That's pretty much expected when running sans hardware video acceleration, and indeed it drops to around 5% using Chromium with VAAPI.

However, and here's the bit I don't understand, when I boot with the Liquorix kernel, total CPU usage playing the same videos in Firefox is more like 4% to 5%, and in line with Chromium/VAAPI.

Firefox in theory doesn't have hardware video acceleration on Linux, but clearly Liquorix is having a positive effect here. The CPU usage for Firefox under Liquorix is closer to that on Windows (with acceleration), and in fact almost 1/3 that of the stock kernel. What gives? Is this a particular patch or setting used for Liquorix but not the stock kernel? I noticed a similar effect on Arch using the linux-ck patched kernel vs stock.

It's definitely an improvement, but again I just wondered if anyone could tell me why? TIA.
Back to top

Take a look at the frequencies your CPU is running at. The default governor for cpufreq/intel-pstate is performance on Liquorix. This means your CPU usage will be lower because there's more CPU headroom when running at higher frequencies.

You can also verify by running i7z. The system running lower clocks will stay in state C0 for longer and have less cores in C6 or later. But running performance, the browser finishes running its decoding / rendering loops faster, thus letting the CPU get back to sleeping sooner.

EDIT: Also, MuQSS accounts for time differently than CFS, so it's better to look at i7z output since you're reading the time in C states, which better indicates CPU usage than time accounted for by the scheduler.

EDIT: EDIT: You didn't specify the kernel you are running in Debian 10, but it could also be that kernel 5.2.x contains some important DRM changes that advertise capabilities in a way that Firefox uses a different code path, or avoids an acceleration blacklist.

FINAL EDIT: My last thought (sorry, I'm coming up with these thoughts on the fly), is MuQSS in Liquorix uses high resolution timers to schedule tasks more precisely in the future. And on top of that, I also changed the default yield behavior to always schedule, which in theory will cause less CPU usage since loops that call yield will spin faster and consume more CPU time if allowed to immediately execute again.
Back to top

I hadn't considered the governor, and you're correct. It's running at full speed continuously under Liquorix and cycles down to 800MHz on the stock kernel. The same(ish) amount of work being a larger percentage of a smaller number hadn't crossed my mind. It sounds like a lot of work has gone into the kernel, MuQSS and so on. I plan to keep using Liquorix regardless, so thanks for all your work.
Back to top