tag:blogger.com,1999:blog-2963790426029213933.post7196145139506623000..comments2024-02-29T00:33:07.382-08:00Comments on Alfred Chen's Blog: PDS 0.98b releaseAlfred Chenhttp://www.blogger.com/profile/03164306846702841944noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-2963790426029213933.post-61888907425780575412017-10-25T08:05:12.513-07:002017-10-25T08:05:12.513-07:00@Alexandre
Sorry for late reply for this topic.
So...@Alexandre<br />Sorry for late reply for this topic.<br />So, based on your test result, 2ms doesn't help much for gaming fps in the above workload. Yes, I agree that low rr interval helps with gaming interactivity under heavy load. But consider low rr interval also introduce switch overhead that impact throughput performance. And as a common scheduler, PDS needs to consider all kinds of usage besides gaming, so the 6ms should be kept as default rr interval.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-31721564746925619252017-10-22T21:33:22.018-07:002017-10-22T21:33:22.018-07:00System: i5-3470@3.20GHz / DDR3 1600@CL9 / Mesa DRI...System: i5-3470@3.20GHz / DDR3 1600@CL9 / Mesa DRI i915.<br /><br />Bare urbanterror 4.3.2 w/ heavy map ut4_suburbs:<br />1. 6ms = ~88 fps<br />2. 2ms = ~88 fps<br /><br />SCHED_IDLE (chrt -i 0 make -j8 + game)<br />3. 6ms = ~74 fps<br />4. 2ms = ~74 fps<br /><br />SCHED_NORMAL (make -j8 + game)<br />6ms = 42~32 fps<br />2ms = 50~28 fps<br /><br />In some map scenarios 6ms is better, mostly the 2ms shows a smooth game with system under heavy load.Alexandre Fradehttps://www.blogger.com/profile/15964702307004146298noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-90090214974266172782017-10-21T10:30:33.372-07:002017-10-21T10:30:33.372-07:00@Alfred:
I'm sorry that I cannot provide the v...@Alfred:<br />I'm sorry that I cannot provide the version info in the way you suggested, but I'll try to keep it as simple as possible and use your current commit No.s of the time I write this here.<br />I'm using the -pf9 patch from Oleksandr that includes PDS 0.98b up to 78339fe.<br />Then reverted "pds: Fix UP compilation issue." 8c48c5e, only to let the next commit revert properly,<br />that is reverting "pds: Reduce policy fairness balance overhead." 2847cfc,<br />then applied inc. patch from kernel.org to 4.13.8.<br /><br />With this setup and the 1000HZ .config, kernel compilation balances both cores at ~95% equally, with the WCG IDLE tasks at ~3% already at the first compilation attempt. IMHO this is the desired behaviour, don't you agree?<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-18726676406097682832017-10-20T17:21:53.297-07:002017-10-20T17:21:53.297-07:00@Manuel
Nice to see you have got a good code base,...@Manuel<br />Nice to see you have got a good code base, but I am a little confused which git reversion your PDS code is at and what commits you have reverted. Would you list 'git log --oneline -- kernel/sched/pds.c' of your kernel tree to show what git reversion you are at?(first 30 lines should be ok) and list what commits you have reverted(if there are not committed in your local copy).<br /><br />Yes, the git commit hash id changed each time I rebase to a new kernel reversion and I have to --fource update the reposiroty branch. It is not a user friendly strategy if you hearvy tracing the pds changes, but if you just fetch the pds code from time to time, that is ok and the pds code are always on the top of the the git log.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-5577987158060614732017-10-20T10:44:32.314-07:002017-10-20T10:44:32.314-07:00@Alfred:
O.k. I remembered correctly. Indeed this ...@Alfred:<br />O.k. I remembered correctly. Indeed this was the kernel compiled after your suggestion from "October 17, 2017 at 5:50 PM", with the above mentioned commits taken out, so this kernel is also without your recent three improvements and still with my custom 512HZ. Kernel compilation reaches around 50-60% on each core, quickly varying upon what's done. <br />Astonishing: I just did one kernel compilation with the old setup for the test, then decided to cancel it (and make clean) to change the .config to 1000HZ to better match your .config -- And now the newly started compilation fills both cores with ~90% each. I don't understand this behaviour, but maybe you find new debugging approaches from this finding.<br />I'd report back soon, after the 1000HZ kernel with the reverted commits got ready and tested.<br /><br />Thanks for your work and BR, Manuel Krause<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-31937099571528894422017-10-20T09:13:21.094-07:002017-10-20T09:13:21.094-07:00@Alfred:
I had written about good balancing result...@Alfred:<br />I had written about good balancing results in "Anonymous -- October 18, 2017 at 2:18 PM", that was with reverted commits "pds: Fix UP compilation issue." (used for following patch reverting only) and "pds: Reduce policy fairness balance overhead." with PDS v0.98b. Please give me an hour or two to re-check that kernel and whether my follow-up observation that only 50% of each core got filled with compilation threads had been correct.<br />(BTW. I'm a little confused by the commit numbers ATM. Do the older ones change each time you add new commits on top?)<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-66240635746208301782017-10-20T08:40:37.573-07:002017-10-20T08:40:37.573-07:00@Manuel
What's the last version of VRQ/PDS you...@Manuel<br />What's the last version of VRQ/PDS you consider as well balanced for your testing work load? If you don't have installed versions on your system, I recommend you test from 145204efa0ee Tag VRQ 0.98.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-73881514319573568632017-10-20T08:24:50.620-07:002017-10-20T08:24:50.620-07:00@Alfred:
Although you were right with your assumpt...@Alfred:<br />Although you were right with your assumption (I had 512HZ), setting it to 1000HZ doesn't make a difference on here, unfortunately. And no related settings like rr_interval was changed. Must be something else.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-20293006385248578392017-10-19T23:40:04.843-07:002017-10-19T23:40:04.843-07:00@Alexandre
Stick with the yield_type topic for thi...@Alexandre<br />Stick with the yield_type topic for this thread, after reconsider the yield things<br />yield_type = 1, the current default, is the most useless type, it just trigger a schedule().<br />yield_type = 2, is most likely the original yield design, which expired the time slice.<br />yield_type = 0, do nothing. Reference to the comments of function yield(void), and you should know why it is not recommended.<br />In next release, the default yield_type will be changed to 0.<br /><br />For the rr_interval, normally I don't recommend to change it as it is related to interactivity and throughput performance balance. But as you have done some tests, I would like to know the result of below scenarios<br />1. Bare ioQuake3 (urbanterror 4.3.2), rr_interval = 6, fps?<br />2. Bare ioQuake3 (urbanterror 4.3.2), rr_interval = 2, fps?<br />3. Kernel compile as IDLE prolicy, make -j8 + ioQuake3 (urbanterror 4.3.2), rr_interval = 6, fps?<br />4. Kernel compile as IDLE prolicy, make -j8 + ioQuake3 (urbanterror 4.3.2), rr_interval = 2, fps?Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-39770584444125346622017-10-19T21:57:17.390-07:002017-10-19T21:57:17.390-07:00Observations to consider.
Building kernel linux m...Observations to consider.<br /><br />Building kernel linux make -j8 + ioQuake3 (urbanterror 4.3.2):<br />rr_interval = 6 (~77 fps)<br />rr_interval = 2 (~115 fps) (xanmod default)<br /><br />Test: 3 latest commits (cc769fc) and yield_type=0 (yield 1/2 same behavior).Alexandre Fradehttps://www.blogger.com/profile/15964702307004146298noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-78558375288776094572017-10-19T17:51:57.345-07:002017-10-19T17:51:57.345-07:00@Manuel
Try 1000HZ if you are not with it. The inb...@Manuel<br />Try 1000HZ if you are not with it. The inbalance issue may be caused by tick interval + next balnace interval > rr interval.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-2488089591216955182017-10-19T10:27:36.949-07:002017-10-19T10:27:36.949-07:00O.k. -- I just made some test setup to provide the...O.k. -- I just made some test setup to provide the things you need.<br />Within the next 30 minutes you'd get the screen captures to your email.<br /><br />ATM I'm watching, that uptime or reusing processes does have some severe impact on balancing/ core's distribution, what a fresh booted system didn't show.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-57047192829892514352017-10-19T09:05:08.886-07:002017-10-19T09:05:08.886-07:00*htop would be best, as I am familar with it, defa...*htop would be best, as I am familar with it, default setting will works<br />*What I want to check is the priority of compiler tasks and the WCG-clients<br />*screenshot would be good<br />Thanks in advanced.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-55148508261427447232017-10-19T08:44:22.572-07:002017-10-19T08:44:22.572-07:00@Alfred:
Sure! -- But, please, first advise me on ...@Alfred:<br />Sure! -- But, please, first advise me on how to provide most valuable info for you:<br />* Screenshot? (With a screenshot I'd be able to send you the info of gkrellm graphs too.) <br />* Special settings to top/htop? <br />* What is better info for you: top or htop?<br />* Something else useful for you?<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-30105423241095589852017-10-19T08:18:35.674-07:002017-10-19T08:18:35.674-07:00@Manuel
Interesting. My test show IDLE task drop b...@Manuel<br />Interesting. My test show IDLE task drop back to about 2~3% on each core while normal tasks are running.<br />Would you please capture a top/htop output so I can inspect tasks status?Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-42698774667479886142017-10-19T06:50:24.693-07:002017-10-19T06:50:24.693-07:00@Alfred:
I've tested with the three most recen...@Alfred:<br />I've tested with the three most recent pds commits applied. Kernel compilation still shows the unbalanced behaviour. <br />Only stopping the IDLE WCG-clients make "make -j2" fill both cores. When then, still in presence of the kernel compilation, WCG-clients are restarted the make job migrates back to the 2nd core again. This looks like no change for me.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-43260301857162999242017-10-19T04:04:30.697-07:002017-10-19T04:04:30.697-07:00@Andrei
Thanks. yield should be killed +1.@Andrei<br />Thanks. yield should be killed +1.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-12620052807283307332017-10-19T03:30:47.341-07:002017-10-19T03:30:47.341-07:00@Alfred Chen
For CPU Atom options yield_type=0 fi...@Alfred Chen<br /><br />For CPU Atom options yield_type=0 fixes problem consistent lockups. Thanks.Andy Lavrhttps://www.blogger.com/profile/06797718949697091110noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-78516871616439209052017-10-18T22:51:36.174-07:002017-10-18T22:51:36.174-07:00@Mitja
Please use yield_type = 0 and see if there ...@Mitja<br />Please use yield_type = 0 and see if there is any side effect.<br />My current plan is set it default 0 in next release, if no complain with it, I tend to totally remove this option.<br />IMO, the yield* API should not be existed. :)Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-37005084667219584632017-10-18T22:37:25.009-07:002017-10-18T22:37:25.009-07:00@Manuel
Please try with this adjustment(https://bi...@Manuel<br />Please try with this adjustment(https://bitbucket.org/alfredchen/linux-gc/commits/cc769fc97f982dceb917900ea2e7560202f91152)Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-48074314241394412802017-10-18T22:05:14.749-07:002017-10-18T22:05:14.749-07:00@alfred
That was spot on. Both yield_type 0 and 2...@alfred<br /><br />That was spot on. Both yield_type 0 and 2 seem to work. I haven't really given it much testing, but the game did start 6 times in a row without problems (first 3 runs with yield_type=0, last 3 runs with yield_type=2). Also yield_type=0 seems to give a slight FPS boost.<br /><br />If you intend to debug this issue I'm willing to try out custom patches. If not, I'm fine with setting the yield_type :)<br /><br />Regards,<br />Mitja Horvat<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-2443240056507150402017-10-18T17:34:53.617-07:002017-10-18T17:34:53.617-07:00@mitja
At this stage, please try different yield_t...@mitja<br />At this stage, please try different yield_type refernece in Documentation/sysctl/kernel.txt and see if it helps.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-84121508530688028612017-10-18T17:12:37.517-07:002017-10-18T17:12:37.517-07:00@Manuel
You can wait for my next_balance adjustmen...@Manuel<br />You can wait for my next_balance adjustment this weekend.<br /><br />@all<br />Sorry that it's a bit busy recent days, so delay for debug load, blog reply etc.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-41994850076924192472017-10-18T14:31:59.488-07:002017-10-18T14:31:59.488-07:00But kernel conmpilation still doesn't outperfo...But kernel conmpilation still doesn't outperform the IDLE tasks. They still get ~50% on each of the 2 cores. Not nice. *MKAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-57245803674635033302017-10-18T14:18:03.763-07:002017-10-18T14:18:03.763-07:00@Alfred:
I've now re-tested it on my own risk....@Alfred:<br />I've now re-tested it on my own risk. Reverted ef7acba77441 first, then reverted aded50b6d382.<br />That brings back, what I want to see (and watch in gkrellm) --> equally used cores. ATM kernel compilation performs faster and looks pretty.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.com