tag:blogger.com,1999:blog-2963790426029213933.post4553912538690476429..comments2024-02-29T00:33:07.382-08:00Comments on Alfred Chen's Blog: PDS 0.98h releaseAlfred Chenhttp://www.blogger.com/profile/03164306846702841944noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-2963790426029213933.post-14385536107540132242018-01-13T06:21:00.498-08:002018-01-13T06:21:00.498-08:00@Alfred:
Sorry, I really don't want to annoy y...@Alfred:<br />Sorry, I really don't want to annoy you: But by chance, would you be able to already provide an inproved patch for 4.14 to test before 4.15.0 shows up?<br /><br />TIA and BR,<br />Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-45842992317993124242018-01-12T05:40:53.741-08:002018-01-12T05:40:53.741-08:00@Eduardo
Thanks for the feedback. I will offical i...@Eduardo<br />Thanks for the feedback. I will offical include this patch in PDS for 4.15 kernel, as it is a little late for 4.14.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-57059631983716628612018-01-12T03:48:10.418-08:002018-01-12T03:48:10.418-08:00@Alfred,
3-4 days of continuous usage on i7 shows...@Alfred,<br /><br />3-4 days of continuous usage on i7 shows no problems. So far so good.<br /><br />Yesterday on Ryzen I observed interesting results while playing POE, there is some sort of weird wine thingy, when in certain maps game slows down by 2/3rds, since I have vsync on PDS + 16ms it dropped from 60 to 20, which I thought is very bad, I booted up standard Ubuntu kernel, FPS dropped down to 15, so PDS does its job VERY well!<br />The fix actually was to disable "multicore" option in game, then it works fine :)<br /><br />Thanks Alfred, very responsive kernel.<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-62330662403371541592018-01-10T09:23:45.114-08:002018-01-10T09:23:45.114-08:00@Alfred:
No problems on here with "16ms_seper...@Alfred:<br />No problems on here with "16ms_seperated.patch" on kernel 4.14.12 for about 48h uptime now.<br /><br />Thank you again for your good work,<br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-66853033534878579352018-01-09T15:38:17.835-08:002018-01-09T15:38:17.835-08:00I need to double check the reverted patch, as I re...I need to double check the reverted patch, as I remembered, there should be some issue with the original code.<br />Will provide patch when I finish checking.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-71841526220412406262018-01-09T15:24:53.940-08:002018-01-09T15:24:53.940-08:00A patched (16ms_seperated.patch) build here:
http...A patched (16ms_seperated.patch) build here:<br /><br />https://deb.xanmod.org/experimental/4.14.12-xanmod17-pds-16ms-balance/Alexandre Fradehttps://www.blogger.com/profile/15964702307004146298noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-85303156203562440802018-01-09T08:38:46.547-08:002018-01-09T08:38:46.547-08:00Cannot Download patch: This repository is currentl...Cannot Download patch: This repository is currently unavailable. Mauricio Aguaidahttps://www.blogger.com/profile/09356261144391290200noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-24704592375658145422018-01-09T08:35:44.093-08:002018-01-09T08:35:44.093-08:00This comment has been removed by the author.Mauricio Aguaidahttps://www.blogger.com/profile/09356261144391290200noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-81834541376941443582018-01-08T13:45:55.321-08:002018-01-08T13:45:55.321-08:00@Alfred,
Smoke test on Ryzen w/ Diablo 3 and Path...@Alfred,<br /><br />Smoke test on Ryzen w/ Diablo 3 and Path Of Exile passed. Installed on i7@work, will see how it fares w/ office type of work.<br /><br />Thanks!<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-15724518634595856422018-01-08T13:00:54.886-08:002018-01-08T13:00:54.886-08:00@Alfred and @Holger:
Just a short question regardi...@Alfred and @Holger:<br />Just a short question regarding this topic: Do you consider issues when just reverting the mentioned yield commit -- so that you elaborate another approach?<br />(Upto 4.14.11 with reverted yield commit and still without 16ms_seperated.patch my system went fine. For 4.14.12 I want to test for some more time.)<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-43501639324683306732018-01-07T16:24:06.587-08:002018-01-07T16:24:06.587-08:00@all
Here comes the patch of balance overhead for ...@all<br />Here comes the patch of balance overhead for your testing. Which is 3/8 of the original overhead, based on my tests, it helps with all kind of workload. But I want you to check the balance behavious in your use cases.<br /><br />https://bitbucket.org/alfredchen/linux-gc/downloads/16ms_seperated.patchAlfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-15431393430319483172018-01-07T16:19:09.314-08:002018-01-07T16:19:09.314-08:00@Holger Hoffstätte
Sorry for the late reply. I'...@Holger Hoffstätte<br />Sorry for the late reply. I'm busy with the test of balance patch. Will provide you another patch for yield later.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-16905906937512576022018-01-02T06:09:16.194-08:002018-01-02T06:09:16.194-08:00Hi Alfred, thanks for your notice.
I reverse-appl...Hi Alfred, thanks for your notice.<br /><br />I reverse-applied the removal commit and it has been working fine for ~4 days now (see https://goo.gl/xxWH3t) on several machines. /proc/sys/kernel/yield_type shows 1 (as expected by documentation & sched_yield() man page).<br /><br />Overall I agree that sched_yield() is a bit questionable to begin with as concurrency and coordination construct, but it exists and is part of POSIX, with (relatively) well-defined semantics. So keeping it is a correctness & compliance issue; I didn't know that the LLVM OpenMP runtime used it for barrier support, but if you know how OpenMP manages threads it kind of makes sense there. For those rare cases where yield_type=0 makes e.g. a game run a little bit better with more FPS, there's always the sysctl knob.<br /><br />Cheers,<br />Holger<br />Holger Hoffstättehttps://www.blogger.com/profile/05303916065597906848noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-44413652945093602772018-01-02T05:14:21.944-08:002018-01-02T05:14:21.944-08:00@all
Thanks all to bring this interesting topic. T...@all<br />Thanks all to bring this interesting topic. To me, sched_yield is like a question "There are many ways to live better, why try to kill youself."<br /><br />I make the current sched_yield changes to PDS not by reading the comments, but I totally agreed with who wrote it, after careful thought,some even philosophical.<br /><br />@Holger Hoffstätte<br />So here is things we can do, please try @Alexandre Frade's suggestion, bring back the yield type support and see if 1 or 2 works for you.<br /><br />If it works, I will consider revert the commit somehow, I need to double check some implementation when do so.<br /><br />@all<br />Thanks all of you for the information shares.<br /><br />Happy new year.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-11785429572365099632018-01-01T07:59:29.173-08:002018-01-01T07:59:29.173-08:00Addendum for reference:
Regarding the latter, '...Addendum for reference:<br />Regarding the latter, 'sched_yield_type', traces @Con Kolivas' blog are:<br />http://ck-hack.blogspot.de/2016/12/linux-49-ck1-muqss-version-0150.html and<br />http://ck-hack.blogspot.de/2016/10/linux-48-ck4-muqss-cpu-scheduler-v0116.html<br /><br />Just for your information, and I don't want to go further back in history.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-19561738069516413392017-12-31T09:11:12.637-08:002017-12-31T09:11:12.637-08:00Unless it makes too much work to maintain related ...Unless it makes too much work to maintain related code, @Alfred, I'd also vote for keeping this _runtime_ configurable option. Let's leave it to users to make their choice upon experience. I just noticed that Con's current MuQSS also keeps this code and sets sched_yield_type = 1 by default. <br />Correspondent patch to revert for PDS would be, after the previous one of course: <br />https://github.com/cchalpha/linux-gc/commit/a82dc71cfbb33298fa757204e6571cf25b4013b5.patch<br />REVERTING sets it to default == 1, as written in the docs. (Just for the records, this came up with "PDS 0.98c release", http://cchalpha.blogspot.de/2017/10/pds-098c-release.html) <br />IIRC, the former base BFS code from Con had set it to 2 until he reconsidered/ reworked it.<br /><br />BR, Manuel Krause<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-77490501068638527772017-12-31T08:08:30.582-08:002017-12-31T08:08:30.582-08:00Holger Hoffstätte,
If you compile your kernel, do...Holger Hoffstätte,<br /><br />If you compile your kernel, download this commit in patch format:<br />https://github.com/cchalpha/linux-gc/commit/493d8652b2dde694ab3d7f3abbb2047d79aa33f3.patch<br /><br />and "git apply --reverse 493d8652b2dde694ab3d7f3abbb2047d79aa33f3.patch"<br /><br />I kept the yield_type support as some xanmod users use this feature.Alexandre Fradehttps://www.blogger.com/profile/15964702307004146298noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-26236832716281248372017-12-30T15:33:08.273-08:002017-12-30T15:33:08.273-08:00I've been really happy with PDS so far since i...I've been really happy with PDS so far since it behaves just as well as MuQSS but has sane time accounting, just like mainline (thanks A LOT for that!). Unfortunately I've just seen that PDS has removed sched_yield() in commit 493d8652 and that has surprising real-world consequences, as can be seen here:<br /><br />https://bugs.gentoo.org/638410<br />https://bugs.llvm.org/show_bug.cgi?id=35731<br /><br />In effect I can now no longer use openmp with clang :(<br /><br />Now I understand that threads giving up their time slice instead of explicit signaling is not that great (since it assumes environment-specific behaviour), but that's no reason to implement sched_yield() as no-op, which just leads to starvation (or test suites running forever). Therefore I'd ask that you restore the sched_yield() support. The github commit still reverse-applies just fine, so it should be easy. :)<br /><br />Also I think the sched_yield_type should be 1 by default (not 0), if only because that's what the comment says..and because that's what anyone would expect as sane behaviour. At least IMHO.<br /><br />Thanks & a happy new year.<br />Holger Hoffstättehttps://www.blogger.com/profile/05303916065597906848noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-57983822671860587342017-12-29T19:55:04.361-08:002017-12-29T19:55:04.361-08:00Thank You!Thank You!anonhttps://www.blogger.com/profile/15323773104710734404noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-49454467268644232222017-12-27T13:38:39.008-08:002017-12-27T13:38:39.008-08:00@Alfred, @pf and all others involved:
Many thanks...@Alfred, @pf and all others involved:<br /><br />Many thanks for your work and collaboration of you others!<br /><br />Together with your improvements and those of the stable 4.14 kernel series, my system got more and more reliable over time, while maintaining the known PDS low-latency.<br />(As I also test the TOI stack, all of these improvements got more relevant, as, besides of all it's limitations, the resume success quote went to 9/9 with kernel 4.14.8 +PDS +TOI)<br /><br />I want to send you my very best wishes for the New Year,<br /><br />and best regards,<br /><br />Manuel KrauseAnonymousnoreply@blogger.com