After 4.9.11 my Ubuntu 16.04 desktop has become less responsive, and at times unstable (large GUIs hanging or consuming massive amounts of cpu - chrome, intellij, eclipse).

The changes listed mention both MuQSS updates, and then a switch to CFS. What motivated the changes in MuQSS, and the change to CFS?

In the meantime, I have been trying out each of the new updates, and end up switching back to 4.9.11, which is stable for me.

Thank you.
Back to top

Hi ds,

I switched back to CFS after experimenting with MuQSS and not being able to come to a compromise on its performance to power draw. Basically, MuQSS by design distributes single tasks among multiple cores more frequently than CFS does. This causes problems where ondemand and schedutil cannot balance between idling cores and providing more power to highly utilized cores.

A great example is if you have 8 cores, and you have a program that uses 100% of two threads. With MuQSS, many applications had issues with low cpu frequencies during full load. A great example is dolphin, where I adjusted the tunables of the ondemand governor to compensate for the way MuQSS distributed its work. Unfortunately, this was not without also making ondemand over-eager, reducing battery life where it shouldn't have.

Here's the commit where I made the change: github.com/zen-kernel/zen-kernel/commit/aff41debf03e13b3c28f8ae1c977d2c267dbbc05

As much as I also enjoyed the performance from MuQSS, when using my work laptop in a mobile state, I also didn't want to burn battery at significantly higher rates than when I was using CFS. What I _can_ do though is reduce the load percentage per core from 95 to maybe something more easily achievable like 80 or 85, when CFS is used. This should help bring some responsiveness back without affecting battery life too much. On MuQSS, in order to get the CPU cores to properly scale when running Dolphin, I had to reduce the percentage to maximum speed to 40% load, which easily causes large increases in frequency / voltage when idling from small background tasks.

I'm still watching the development of MuQSS, but I'd like to see some changes in how MuQSS interacts with the governors, or vice versa, before I make the decision to switch back. For now, Liquorix will be staying on CFS until I see a positive change in the cpufreq domain.
Back to top

Hello.

Thanks for the reply.

I have just tried out 4.9.0-16.1-liquorix-amd64 and am seeing the same lack of desktop user responsiveness in my environment; an always A/C powered desktop with a quad core Intel i7-3820. My use case typically involves running background jobs that consume all 4 cores with heavy CPU loads (parallel compilation and testing, C++, Java, Maven), while at the same time running as a desktop GUI user (X, Unity, Chrome, IDE, lots of terminals, etc...). During the heavy CPU loads, my interactive sessions show significant lag in keyboard, mouse, and redraw. Moving back to 4.9.0-11.1-liquorix-amd64 eliminates this effect.

It was this lack of responsiveness in the stock Ubuntu 16.04 / 4.4 kernels that drew me to Liquorix.

Can you suggest a course of action I can take for improving the interactive performance of this system while still running current Liquorix releases? Is there runtime scheduler tuning that I can do?

Thank you,

David Stone
Back to top

Yes, it appears that you're correct. I made a pretty bad judgement call when handling the battery life problem.

I switched the process scheduler back to MuQSS and I'll focus instead on seeing if I can correct the frequency scaling by means of using intel_pstate on Intel CPUs, or by using some type of objective measurement to find the goldilocks configuration in ondemand where the frequency scales appropriately, balancing battery life and throughput to some degree.

Check the new build released today, 4.9.0-17.1 / 4.9-19, if you want a recent kernel using MuQSS.

Sorry for the inconvenience!
Back to top

No problem. And thank you for switching back to MuQSS, 4.9.0-17.1-liquorix-amd64 appears to be behaving fine on my system.
Back to top