Not a member yet? Why not Sign up today
Create an account  

  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
PDS-mq vs MuQSS

#1
Photo 
I noticed that 4.14 xanmod 5 and 6 uses MuQSS cpu scheduler, as opposed to xanmod 1 through 4 of the 4.14 branch that used the PDS-mq cpu scheduler.

When i upgraded at first, i noticed sliiightly worse wine gaming performance, but more or less had it all figured down to wine being.. uhm.. wine, so did not pay that much attention.. but well.. 1 fps here, and 1 fps there Smile

So.. Following two screenshots are from PDS-mq kernel 4.14.2-xanmod4, and next from MuQSS 4.14.3-xanmod6.
PDS-mq
MuQSS

Not really sure why MuQSS seem to use my HT threads a lot more? The fps is 4-5 fps less with MuQSS when i play World of Warcraft under Wine (2.18-staging). Not a lot, but from 40'ish fps its 10% Smile Using HT threads for gaming is kind of a bummer i guess, but should not be a problem tho..

Just my puter behaving badly? Anyone else done any sort of benchmarks or similar that can tell me im full of sh**t? Smile

C
Reply

#2
PDS is faster than MuQSS also in my system, but it's less stable under interactive workload scenarios and multitask demands. However, we should consider this uncommon events mostly as brief time to get finally the 4.15 series, so don't be afraid at all of 4.14 LTS flavour related with less speed or less development because this is actually the latest LTS branch with its specifics needs along time. I sure you that 4.15 series will be one of the best XanMod series ever. Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#3
Not really sure how i should interpret this tho tropic?

Am I to understand I should just wait until 4.15 cos "then its really performance", when 4.14 has MORE performance than 4.13, and 4.12? Smile

Not to nitpick too much, but I'm currently using 4.14.2 with PDS-mq as it gives a bit more performance when gaming. Can't say I have noticed any instability in other usage desktop/compiling stuff/writing/printing/youtube.. or whatever.

I guess Linux + any sort of gaming is "uncommon event", so I can understand the idea that stability/responsiveness > performance when it comes to Linux kernel's.

Well.. 4.15 will possibly be 2017 christmas gift this year then Smile

C
Reply

#4
CybDex,

Thanks for the feedback.

Try to turn off interactive (root):
Code:
echo 0 > /proc/sys/kernel/interactive

https://forum.xanmod.org/thread-201.html

Note: In 4.14.4-xanmod7 smt_nice has been disabled.
Reply

#5
(05-12-2017, 08:27 PM)Alexandre Frade Wrote: CybDex,

Thanks for the feedback.

Try to turn off interactive (root):
Code:
echo 0 > /proc/sys/kernel/interactive

https://forum.xanmod.org/thread-201.html

Note: In 4.14.4-xanmod7 smt_nice has been disabled.

Ill give it a test with that interactive setting and see what load result i come up with :Smile

Thanks!! Smile

C
Reply

#6
Did some testing using wine and Unigine Heaven benchmark.

Yesterday switching between interactive 0 vs 1 made little difference. Still slower (probably expected) than with PDS-mq.

Today i saw xanmod7 was upgraded. Change was: CONFIG_RQSHARE_SMT=y vs CONFIG_RQSHARE_MC=y

And now, the difference is HUGE with interactive=1 vs 0. Heaven benchmark is more or less a slideshow with interactive=1.. totally unusable. Setting it to 0 its similar to what it was yesterday. Still slower than PDS-mq tho, but as I said I guess its to be expected Smile

Will use it a bit like that, and test some back and forth..

I use the following line in my "gaming" script for this:

Code:
sudo sh -c "echo '0' >> /proc/sys/kernel/interactive"

C
Reply

#7
Ok, I'm considering going back to pds-mq.
Reply

#8
(07-12-2017, 01:49 AM)Alexandre Frade Wrote: Ok, I'm considering going back to pds-mq.

Although i appreciate it, i just read a comment from one experiencing instability with it, so I feel I can't really ask you to do that.. however, if it was possible to put up a own PDS-mq flavor, that would be just perfect Smile

Dunno the limitations or bandwidth/space++ from the repository, or if it in any way will cause your problems, cos I'm just one nosy guy, and don't really wanna cause a fuss about it Smile

Keep up the awesome work tho! Really appreciate it Smile

C
Reply

#9
That probably was me. Every time I play Overwatch using Wine with a PDS kernel, I completely freeze up. On some of them, it was freezing till the game d/ced, after which I could continue. Other times a complete lockup.

So I stayed on the last CFQ kernel for a while. (linux-4.13.5-xanmod10)

MuQSS with "/proc/sys/kernel/interactive" set to throughput though, feels really good, especially during teamfights, where all my 4 cores (no HT), are getting getting around 90% load, and you are dropping a bit in fps. I think this is because the same thread is staying on the same core. I have HTop running on another screen while playing, and normally I see the biggest load thread (main game thread?) jumping from core to core, but with MuQSS it stay on the same core consistently. I think that gives a very smooth feeling in gameplay.

Going to test this with WoW tomorrow.

Dox
Reply

#10
Hmm.. seems as the "CONFIG_SMT_NICE=y" is a bit "nice'er" to the HT cores Smile

C
Reply

#11
Tested! (WoW with MuQSS on 4.14.4-xanmod7 with "througput")

It is absolutely great that the same threads keep getting scheduled on the same core. Well, it is me assuming it is the reason everything feels is smoother, and fps is higher. I have only done a cursory glance at the documentation about MuQSS and Xanmod kernels configuration.


Anyways, I'm quite happy with MuQSS Xanmod kernel. Thanks.

Let me know if you have any other suggestions for testing,

Dox
Reply

#12
Running games under wine, w/ yield_type 0 or 2 can help.

Code:
echo 0 > /proc/sys/kernel/yield_type

https://forum.xanmod.org/thread-201.html
Reply

#13
(10-12-2017, 02:13 AM)Alexandre Frade Wrote: Running games under wine, w/ yield_type 0 or 2 can help.

Code:
echo 0 > /proc/sys/kernel/yield_type

https://forum.xanmod.org/thread-201.html

Hmm.. would this help with PDS too? Even MORE than PDS already does i mean Wink 

Will give it a go.. Theoretically i would not know why PDS gives 3-5 fps (out of 40'ish) more in WoW and 5-6 (out of 80) in Heaven benchmark tho.. Hmm perhaps i should compare Linux native OpenGL Heaven benchmarks just to do that aswell then.

C
Reply

#14
Going crazy with the scenery from Heaven atm, so I will stop benching.

I tried that, cos it was a easy benchmark to reproduce, but alas the results are not really consistent. I can run once get a result, test a setting, then get a different result, and back to previous and get a different result.

The only thing that was noticable different was when changing to interactive=0. Horrible stutters compared to 1, so thats atleast a +.
It SEEMS as yield_type=0 gave the highest scores over a few runs, but as said earlier... cant really be reproduced to a consistent state.

Benchmarking in World of Warcraft is something i have also tried to do, but it has quite a few dependencies and is somewhat not 100% consistent either, so its more of a "feeling" kind of thing, and for now PDS feels the fastest.. but then again so does CFS scheduler thats in mainline and release kernel. The other tweaks, BFQ io scheduler and other stuff from Xanmod more than weight up for using that, so i wont go the route back to mainline/release kernel tho.

Stick with it Alexandre Smile Thanks for the hard work.. And we shall see what 4.15 kernel brings when that gets released!

C
Reply

#15
Tested yield settings with WoW already, that didn't give any noticable difference.

For OW on Wine, my gut feeling is that yield set to 2 is better.

However, in both cases, I already have Wineserver set to realtime priority, and the games itself I start with nice -15. So that will have affect on scheduling a bit. I'm going to stick with that setting it to interactive to "throughput" simply keeps thread on the CPU core, which for my i5-4670k seems to work the best.

So bottom-line seems to be, we need 2 kernels, 1 with PDS, and 1 with MuQSS! But I guess we will just w/e kernel version that has the scheduler we want. Wink

Cheers, and thx for kernel again!

Dox
Reply

#16
Did some tests with Unigine Heaven again, and although the end-result in type of score is non-conclusive, i tested standing at the same spot and viewing core usage in htop + the gpu usage from nvidia-smi.

With xanmod8 - MuQSS
FPS: 49-51
Cpu cores evenly around 55-60%
HT cores evenly around 30-35%
Gpu usage: 70%

This was done with interactive=0. Setting yield_type did not affect this to any degree.

Test with Xanmod2 - PDS
FPS: 67-68
Cpu cores: Core 1+2 - 75-77%, core 3 - 52-54%, core 4 - 30-35%
HT cores evenly around 16-18%
Gpu usage: 97-98%

nVidia driver - 387.34, wine-staging-2.18

At the same spot, with same settings on the scene, the gpu utilization and fps favors PDS... and when it comes to gaming i have no problem with higher load on 3 cores vs. even spread at a lower rate, if it means more fps Smile

Not really sure why this happens, but the way wine utilizes threads and __GL_THREADED_OPTIMIZATIONS might have something to do with MuQSS not behaving optimal? I (aswell as Dox it seems) have experienced wine games/games in general performing better with CFS kernel, but at the cost of crap interactivity. I haven't tested mainline/stable kernel with cfs in a while, but seem to remember having some issues if i tried to play youtube videos on my 2nd monitor while playing wow.. things like that. I might just do a similar number test with mainline for comparison..

Is PDS-mq something inbetween CFS and MuQSS you think?

Having best of all worlds would be to have CFS/PDS/MuQSS choosable in the same way io schedulers are.. or atleast a kernel option so one would not have to keep 2 kernels i guess Smile

C

That did not take too long.. Tested with both mainline 4.14.2 and 4.14.5 and had equal result.

FPS: 49-50
Cpu cores - 27-32%
HT cores - 27-32%
Gpu usage: 70-74%

Equal fps, but at a slightly lower overall cpu usage (cores and HT cores seemingly equally distributed).
So, atleast MuQSS is aware of HT cores, and tries to avoid putting equal load across all "cores", perhaps at the cost of more cpu usage vs. the same result? PDS does this job better it seems...

C
Reply

#17
Please test the build with pds and muqss without rqshare.

http://deb.xanmod.org/experimental/

install the image and headers packages.


Also try running on SCHED_FIFO or SCHED_RR policy:
Code:
sudo chrt -f 10 'game'

See: man chrt or chrt --help

Notes:
CFS / PDS / MuQSS: SCHED_OTHER
Real-time FIFO/RR scheduling is independent of being cfs, muqss or pds kernels.
Reply

#18
Thanks for your hard work!

4.14.5-xanmod8-pds had the same performance as 4.14.2-xanmod2, so nothing has changed there.
4.14.5-xanmod8-rqsharenone i could not get to boot at all. Just hang at "loading initial ramdisk". Did "sudo update-initramfs -k 4.14.5-xanmod8-rqsharenone -u", but still same problem. So.. no boot.

Tried to fiddle with the chrt, and it seems as Wine runs some sort of internal scheduling. I also have a wine setting with STAGING_RT_PRIORITY_SERVER=90 that should do something internally to prioritize this higher.
The reason i said "tried to fiddle" is when i changed the scheduling policy it crashed. Both with -f (FIFO) and -r (RR) caused a total hang with 1 core at 100%, gpu core at 0% and program locked (In this case Unigine Heaven).

http://repo.or.cz/w/wine-rt.git/blob/win...ME.WINE-RT

Not sure how relevant that post is for 2.x theese days, but well.. Did not have much success with the chrt command.

Anyways, thanks for the updated xanmod8-pds tho Smile

C
Reply

#19
(14-12-2017, 03:21 PM)CybDex Wrote: Thanks for your hard work!

4.14.5-xanmod8-pds had the same performance as 4.14.2-xanmod2, so nothing has changed there.
4.14.5-xanmod8-rqsharenone i could not get to boot at all. Just hang at "loading initial ramdisk". Did "sudo update-initramfs -k 4.14.5-xanmod8-rqsharenone -u", but still same problem. So.. no boot.

Tried to fiddle with the chrt, and it seems as Wine runs some sort of internal scheduling. I also have a wine setting with STAGING_RT_PRIORITY_SERVER=90 that should do something internally to prioritize this higher.
The reason i said "tried to fiddle" is when i changed the scheduling policy it crashed. Both with -f (FIFO) and -r (RR) caused a total hang with 1 core at 100%, gpu core at 0% and program locked (In this case Unigine Heaven).

http://repo.or.cz/w/wine-rt.git/blob/win...ME.WINE-RT

Not sure how relevant that post is for 2.x theese days, but well.. Did not have much success with the chrt command.

Anyways, thanks for the updated xanmod8-pds tho Smile

C

Should be an unsuccessful download. Please download again. The only difference is the config with RQSHARE_NONE=y. It should not be a problem.
Reply

#20
(14-12-2017, 06:29 PM)Alexandre Frade Wrote: Should be an unsuccessful download. Please download again. The only difference is the config with RQSHARE_NONE=y. It should not be a problem.

I was not aware that it was possible for dpkg to install a partially downloaded .deb file successfully with no errors. DKMS compiles the nVidia drivers and everything. It just hard-locks when booting, and i have to reset/powerbutton to reboot. Same problem after purging non-working package and re-downloading.

C
Reply



[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Forum Jump:


Users browsing this thread:
1 Guest(s)