I used to drag a 5.11 kernel because that was the last one I could use with your patches and it made my old and tired computer usable while it was doing other stuff as well, like compiling(I'm a Gentoo user). Since then I've moved to a much more recent hardware (Ryzen 7 8c/16t). I was very happy to see you renewed your patch line because there were multiple changes in the main line kernel in scheduling which affected responsiveness and some of them were quite disappointing. I thought I can finally go back to the so much desired behaviour of MuQSS. Unfortunately I didn't see a positive change. I think it even lead to stuttering which I hadn't observed recently. Not only that but it looked like my CPU can't be loaded beyond 50-55%. And that was not subjective perception, the fans were not spinning as they used to spin when compiling Firefox. To summarise: CPU cannot be loaded beyond say 60% and still I was getting stuttering. I hope this feedback helps somehow.
Your conclusion is completely unfounded and disrespectful btw. I've just reproduced it with you 7.3 kernel. I was going to replay to your above replay when I decided to conduct another test. I had left my terminal from last night with the command typed in it to do the first thing in the morning: /usr/src/linux-7.3-ck1 # make -j16 I pressed enter and watched how it maxed out all my cores and had 16 instances of cc. I compiled, rebooted in it, make clean, make -j16 again and watched it max out the cores again. I decided to play a YouTube video although the stuttering I observed was in one of my VM's. I didn't feel like recreating the conditions so I settled on the simple YT test. I said to myself, well maybe I got this wrong. I terminated the compilation, but then I wanted to test again a particular part of the video I observed looked stuttery. I `make clean`, `make -j16` again and voila. The same pattern. The fans were quieter than usual, the complete load was sustained around 50-55%, I never saw it go above 60 for very short periods of time. During all the time I observed the load go to 100% just for a brief moment near the end of compilation.
I did that a third time - same behaviour.
So this adds some more context: first time I was running a system update, Firefox (or actually Librewolf) was the last one of the updates. It must have loaded the CPU to 100% at the beginning with some of the first updates but then the next round of compilation must have fallen to 50-60% CPU utilisation for me to notice it. And don't forget the slight stuttering. I think it's real because I have never observed it before. Also it makes Librewolf act weird. I can't explain exactly how but one part is it sometimes does not load pages at all. I need to completely close the tab and load the page anew. It also doesn't follow redirects all the time and is kind of more unresponsive. Also the cursor does not appear when typing.
Thanks for that. The only thing not tested in your config is LLC sharing which was contributed code. Can you try booting with "rqshare=mc" and "rqshare=none" separately and test? No rebuild required.
Both options behave the same. The first run loads the CPU to nearly 100%, then the subsequent runs load to ~55%. Now this is 100% related to using your changes but I suspect it's not the only piece of the puzzle in play because the behaviour I observe happens in a graphic terminal under Wayland(Hyprland/UWSM/systemd) but not under the FB console. I know it's related to the -ck kernel because I can't reproduce the same behaviour with the mainline sources. It's worth noting that the only mainline sources I've used so far are 6.18.54. I'm now compiling unmodified 7.3.0 to see how it behaves.
Thanks. It is a most unusual bug report because there are only two scenarios where MuQSS would not load up a CPU to 100%, and in both cases it would be a conscious scheduling decision by the user - either running a niced task, or sched IDLE task in the presence of another load running on a CPU SMT sibling and there is no other CPU available either due to them being busy or due to CPU affinity. Now if you're not consciously using nice, scheduler policies, or CPU affinities, then it must be something else. Reporting it happening only under wayland is even weirder. Perhaps this is an artefact of cgroup and something in your distribution is using them - cpu cgroups are not implemented in muqss, they're just blind stubs so should have no effect though. So I'm stumped as to what may be causing your issue; especially if it's 100% on first run and then 55% after.
I thought something of cgroups too, but I'm not familiar with that matter. Next thing I thought was UWSM which does some systemd magic but again I'm not sure if that is related at all and also I'm not clear on what is it that it does. Well at this point I'm out of ideas. Just keep that in mind, something may pop up that may be related. I'll continue trying consequent versions and I hope something comes to my mind that could be useful.
I thought of one other change unique to 7.3-ck1, the minimum timeout for timers was dropped to 100us which might interact with some hardware you have. You can try changing it to the mainline value with echo 1000 > /proc/sys/kernel/hrtimeout_min_us
I used to drag a 5.11 kernel because that was the last one I could use with your patches and it made my old and tired computer usable while it was doing other stuff as well, like compiling(I'm a Gentoo user). Since then I've moved to a much more recent hardware (Ryzen 7 8c/16t).
ReplyDeleteI was very happy to see you renewed your patch line because there were multiple changes in the main line kernel in scheduling which affected responsiveness and some of them were quite disappointing. I thought I can finally go back to the so much desired behaviour of MuQSS.
Unfortunately I didn't see a positive change. I think it even lead to stuttering which I hadn't observed recently. Not only that but it looked like my CPU can't be loaded beyond 50-55%. And that was not subjective perception, the fans were not spinning as they used to spin when compiling Firefox. To summarise: CPU cannot be loaded beyond say 60% and still I was getting stuttering.
I hope this feedback helps somehow.
You are confusing spreading load to all CPUs with not loading a CPU.
DeleteYour conclusion is completely unfounded and disrespectful btw.
DeleteI've just reproduced it with you 7.3 kernel. I was going to replay to your above replay when I decided to conduct another test. I had left my terminal from last night with the command typed in it to do the first thing in the morning: /usr/src/linux-7.3-ck1 # make -j16
I pressed enter and watched how it maxed out all my cores and had 16 instances of cc.
I compiled, rebooted in it, make clean, make -j16 again and watched it max out the cores again. I decided to play a YouTube video although the stuttering I observed was in one of my VM's. I didn't feel like recreating the conditions so I settled on the simple YT test.
I said to myself, well maybe I got this wrong. I terminated the compilation, but then I wanted to test again a particular part of the video I observed looked stuttery. I `make clean`, `make -j16` again and voila. The same pattern. The fans were quieter than usual, the complete load was sustained around 50-55%, I never saw it go above 60 for very short periods of time. During all the time I observed the load go to 100% just for a brief moment near the end of compilation.
I did that a third time - same behaviour.
So this adds some more context: first time I was running a system update, Firefox (or actually Librewolf) was the last one of the updates. It must have loaded the CPU to 100% at the beginning with some of the first updates but then the next round of compilation must have fallen to 50-60% CPU utilisation for me to notice it. And don't forget the slight stuttering. I think it's real because I have never observed it before.
Also it makes Librewolf act weird. I can't explain exactly how but one part is it sometimes does not load pages at all. I need to completely close the tab and load the page anew. It also doesn't follow redirects all the time and is kind of more unresponsive. Also the cursor does not appear when typing.
Okay. Is your make -j16 niced? Do you have an SMT kernel? Do you enable SMT nice in the config? Have you enabled I/O aware scheduling?
DeleteThis is my kernel config: https://dpaste.com/ADRZMSLQN
Deletemake is not niced, I don't usually do that.
DeleteThanks for that. The only thing not tested in your config is LLC sharing which was contributed code. Can you try booting with "rqshare=mc" and "rqshare=none" separately and test? No rebuild required.
DeleteBoth options behave the same. The first run loads the CPU to nearly 100%, then the subsequent runs load to ~55%. Now this is 100% related to using your changes but I suspect it's not the only piece of the puzzle in play because the behaviour I observe happens in a graphic terminal under Wayland(Hyprland/UWSM/systemd) but not under the FB console. I know it's related to the -ck kernel because I can't reproduce the same behaviour with the mainline sources. It's worth noting that the only mainline sources I've used so far are 6.18.54.
DeleteI'm now compiling unmodified 7.3.0 to see how it behaves.
Nope, I can't reproduce it with unmodified 7.3.
DeleteThanks. It is a most unusual bug report because there are only two scenarios where MuQSS would not load up a CPU to 100%, and in both cases it would be a conscious scheduling decision by the user - either running a niced task, or sched IDLE task in the presence of another load running on a CPU SMT sibling and there is no other CPU available either due to them being busy or due to CPU affinity. Now if you're not consciously using nice, scheduler policies, or CPU affinities, then it must be something else. Reporting it happening only under wayland is even weirder. Perhaps this is an artefact of cgroup and something in your distribution is using them - cpu cgroups are not implemented in muqss, they're just blind stubs so should have no effect though. So I'm stumped as to what may be causing your issue; especially if it's 100% on first run and then 55% after.
DeleteI thought something of cgroups too, but I'm not familiar with that matter. Next thing I thought was UWSM which does some systemd magic but again I'm not sure if that is related at all and also I'm not clear on what is it that it does.
DeleteWell at this point I'm out of ideas. Just keep that in mind, something may pop up that may be related. I'll continue trying consequent versions and I hope something comes to my mind that could be useful.
Thanks. Like I said none of that behaviour makes any sense, so if you find out anything, please pass it on.
DeleteI thought of one other change unique to 7.3-ck1, the minimum timeout for timers was dropped to 100us which might interact with some hardware you have. You can try changing it to the mainline value with
Deleteecho 1000 > /proc/sys/kernel/hrtimeout_min_us