MuQSS Updates For The Linux 4.10 Kernel

[dungeon]

Fedora is a minor distribution compared to Debian and Debian based. Gnome3 is a good hand break. 1000 Hz kernel and wayland is need for trying gnome3 to be usable. Gnome3 is full of bugs and constant development, never ready.

Fedora uses 1000Hz for decade, probably more whatever but for sure even before Gnome 3... Ubuntu lowlatency kernel flavor also uses 1000Hz, etc... you can't say that is barely tested

My kernel config is the state of the art, see:
https://www.phoronix.com/forums/foru...in-living-room

You are in the state of mess with Ubuntu PPAs on Debian Also your filedropper link somehow does not work as expected

[Ropid]

You'll probably have to test this. From experience, BFS offered somewhat better responsiveness when the system was under full load, but it had *massive* core hopping issues, cutting down the single-threaded performace in half when using the ondemand governor - I'm currently compiling a -ck kernel to test whether this has been resolved with MuQSS.

Edit: No, it hasn't, single-threaded tasks still perform poorly, hopping around between Cores 0-2 while cores 3-5 are doing absolutely nothing. With CFS there's hardly any hopping, but CFS doesn't even allow me to watch youtube videos while compressing something with pbzip2 in the background. Meh.

Performance should still be virtually the same even with the thread jumping around between cores. You'll see it if you benchmark it. That's how it always was with CFS vs. BFS when I tried to benchmark it here for me.

What's probably happening behind the scenes is that there's a race between the cores to fetch the interrupted task from the queue. That should be what's causing a thread to switch cores. If there's really a different core faster done with its task scheduling business, this little bit of gained time might offset downsides of the switch with regards to caches or whatever.

[cj.wijtmans]

You'll probably have to test this. From experience, BFS offered somewhat better responsiveness when the system was under full load, but it had *massive* core hopping issues, cutting down the single-threaded performace in half when using the ondemand governor - I'm currently compiling a -ck kernel to test whether this has been resolved with MuQSS.

Edit: No, it hasn't, single-threaded tasks still perform poorly, hopping around between Cores 0-2 while cores 3-5 are doing absolutely nothing. With CFS there's hardly any hopping, but CFS doesn't even allow me to watch youtube videos while compressing something with pbzip2 in the background. Meh.

your mistake is using the ondemand governer in the first place.

[VikingGe]

Performance should still be virtually the same even with the thread jumping around between cores. You'll see it if you benchmark it. That's how it always was with CFS vs. BFS when I tried to benchmark it here for me.

Well I did, and that's why I'm complaining. Compared to CFS I'm losing roughly 10% when the system is (almost) completely idle, and anything from 20%-30% when there's mild background load (e.g. when playing a youtube video in Vivaldi). Core hopping *is* an issue when the task is continuously re-scheduled to a core that is running at less than half its maximum clock speed.

your mistake is using the ondemand governer in the first place.

What else should I be using with an overclocked Phenom II without wasting massive amounts of electricity? Performance is not an option with those chips.
I haven't tried schedutil with -ck though, maybe that's worth a shot (assuming MuQSS makes use of it at all).

[Ropid]

Well I did, and that's why I'm complaining. Compared to CFS I'm losing roughly 10% when the system is (almost) completely idle, and anything from 20%-30% when there's mild background load (e.g. when playing a youtube video in Vivaldi). Core hopping *is* an issue when the task is continuously re-scheduled to a core that is running at less than half its maximum clock speed.


What else should I be using with an overclocked Phenom II without wasting massive amounts of electricity? Performance is not an option with those chips.
I haven't tried schedutil with -ck though, maybe that's worth a shot (assuming MuQSS makes use of it at all).

The way I understood it, all cores share the same clock and always run at the same clock speed. Software showing different speeds between different cores is not really what the hardware does at that moment.

Perhaps what's happening is that the on-demand governor is getting confused and reduces clock speed, because with that thread hopping around, it sees for example 33% usage on three cores instead of 100% usage on a single core.

You could maybe ask in the comments on the -ck blog? It allows anonymous posting so no need to sign up for an account or anything. This thing here could be a bug. I think there was something about the task scheduler being able to communicate to the on-demand governor in the newest kernel versions? There might be a way CK could fix this problem.

[VikingGe]

The way I understood it, all cores share the same clock and always run at the same clock speed. Software showing different speeds between different cores is not really what the hardware does at that moment.

That actually depends on the CPU. Quoting Anandtech:

The original Phenom processor had the ability to adjust the clock speed of each individual core. AMD disabled this functionality with the Phenom II to avoid some performance problems we ran into, but it’s back with Thuban.

cpupower monitor also confirms this, it reads the MSRs that report the number of actually executed clocks.
Not sure how Intel chips handle things though.

I hacked this together a while back, it tries to measure the actual clock speed while stressing a single core, with the original intent of measuring the latency of the governor. With a large enough number of samples it shows the issue.

I think there was something about the task scheduler being able to communicate to the on-demand governor in the newest kernel versions?

Wasn't that what schedutil is for? ondemand is entirely reactive AFAIK.

[mitch074]

So with Ryzen offering 8 core 16 thread and later a 16 core 32 thread variant, are you better off with CFQ with such a CPU or would BFQ or MuQSS have something to offer? I'm planning on a high core count CPU later in the year for a desktop/workstation machine where the extra cores will help a bunch with running VMs and other workloads. Even just as a regular desktop use case with one of those CPU would BFQ/MuQSS have a negative impact on the system with that hardware?

As said, MuQSS does take multicore systems into account but retains the rest of the philosophy behind BFQ; the latter is unmaintained for years now anyway.

[dkasak]

The mainline kernel is barely tested with 1000Hz kernel timer, try that and you notice some glitches when using a desktop

I've been running 1000Hz kernels for years and had great success. What problems have you had?