PDS 0.98h is released with the following changes
4 fixes for different compile warning/error on other architecture or with other kernel config. Thanks jwh7, pf, Alexandre Frade and -pf kernel/xanmod users who reported these issues.
This is a bug fix release. It will be the last PDS release before Xmas and new year holiday. Again, thanks for testing/reporting/supporting to make PDS progressing this year.
Enjoy PDS 0.98h for
v4.14 kernel, :)
code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.14.y-pds
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.14.y-pds
All-in-one patch is available too.
@Alfred, @pf and all others involved:
ReplyDeleteMany thanks for your work and collaboration of you others!
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.
(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)
I want to send you my very best wishes for the New Year,
and best regards,
Manuel Krause
Thank You!
ReplyDeleteI'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:
ReplyDeletehttps://bugs.gentoo.org/638410
https://bugs.llvm.org/show_bug.cgi?id=35731
In effect I can now no longer use openmp with clang :(
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. :)
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.
Thanks & a happy new year.
Holger Hoffstätte,
DeleteIf you compile your kernel, download this commit in patch format:
https://github.com/cchalpha/linux-gc/commit/493d8652b2dde694ab3d7f3abbb2047d79aa33f3.patch
and "git apply --reverse 493d8652b2dde694ab3d7f3abbb2047d79aa33f3.patch"
I kept the yield_type support as some xanmod users use this feature.
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.
DeleteCorrespondent patch to revert for PDS would be, after the previous one of course:
https://github.com/cchalpha/linux-gc/commit/a82dc71cfbb33298fa757204e6571cf25b4013b5.patch
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)
IIRC, the former base BFS code from Con had set it to 2 until he reconsidered/ reworked it.
BR, Manuel Krause
Addendum for reference:
DeleteRegarding the latter, 'sched_yield_type', traces @Con Kolivas' blog are:
http://ck-hack.blogspot.de/2016/12/linux-49-ck1-muqss-version-0150.html and
http://ck-hack.blogspot.de/2016/10/linux-48-ck4-muqss-cpu-scheduler-v0116.html
Just for your information, and I don't want to go further back in history.
BR, Manuel Krause
@all
DeleteThanks 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."
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.
@Holger Hoffstätte
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.
If it works, I will consider revert the commit somehow, I need to double check some implementation when do so.
@all
Thanks all of you for the information shares.
Happy new year.
Hi Alfred, thanks for your notice.
DeleteI 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).
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.
Cheers,
Holger
@Holger Hoffstätte
DeleteSorry for the late reply. I'm busy with the test of balance patch. Will provide you another patch for yield later.
@Alfred and @Holger:
DeleteJust a short question regarding this topic: Do you consider issues when just reverting the mentioned yield commit -- so that you elaborate another approach?
(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, Manuel Krause
I need to double check the reverted patch, as I remembered, there should be some issue with the original code.
DeleteWill provide patch when I finish checking.
@Alfred:
DeleteSorry, 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?
TIA and BR,
Manuel Krause
@all
ReplyDeleteHere 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.
https://bitbucket.org/alfredchen/linux-gc/downloads/16ms_seperated.patch
@Alfred,
DeleteSmoke 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.
Thanks!
BR, Eduardo
@Alfred:
DeleteNo problems on here with "16ms_seperated.patch" on kernel 4.14.12 for about 48h uptime now.
Thank you again for your good work,
BR, Manuel Krause
@Alfred,
Delete3-4 days of continuous usage on i7 shows no problems. So far so good.
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!
The fix actually was to disable "multicore" option in game, then it works fine :)
Thanks Alfred, very responsive kernel.
BR, Eduardo
@Eduardo
DeleteThanks for the feedback. I will offical include this patch in PDS for 4.15 kernel, as it is a little late for 4.14.
This comment has been removed by the author.
ReplyDeleteCannot Download patch: This repository is currently unavailable.
ReplyDeleteA patched (16ms_seperated.patch) build here:
ReplyDeletehttps://deb.xanmod.org/experimental/4.14.12-xanmod17-pds-16ms-balance/