PDS 0.98n is released with the following changes
1. Migrate max SCHED_RQ_NR_MIGRATION tasks to empty rq at a time. This will help with burst situation.
2. Code cleanup.
3. Optimize scheduler_tick(), pds_sg_balance() and pds_load_balance(). This helps with overhead reduction.
With the help of optimization in this release, improvement can be observed in sanity tests(for all kinds of workload). PS, there will be no cachehot patch coming, as there is overhead cutting in ttwu code path in 0.98m, and leave no improvement space for the cachehot patch.
Enjoy PDS 0.98n for
v4.16 kernel, :)
code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.16.y-pds
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.16.y-pds
All-in-one patch is available too.
@Alfred:
ReplyDeleteQuite a little early to make serious conclusions, but this seems to be a promising release, again. :-) Compiled and booted well and works fine in my usual use.
It can be, that there are also great improvements for desktop interactivity. I've observed this with scrolling in Firefox without lags.
Thank you for your valuable work and all the invested time,
BR, Manuel Krause
Built and running on x64 and x86-UP; fine so far. Thanks Alfred
ReplyDeleteThanks.
ReplyDeleteThanks for the feedback. I will continue looking for the code optimization and overhead cutting. Next release will be about 2 weeks later.
ReplyDelete@Alfred:
DeleteAlso after almost 48h of uptime the positive effects remain valid. The overall experience is now, IMO, even better than with the CacheHot experiment.
It's also nice to read, that you see even more potential for improvements. Looking forward to it. :-)
If you find some time, could you please explain the terms "burst situation" from your top posting's first point a little more? What does it mean for both theory and praxis?
TIA, Manuel Krause
I have been using this version for some time and there are zero issues on Ryzen@home and i7@work.
ReplyDeleteGlobally it seems, at least, a bit more responsive on both computers than previous releases, no numbers though.
In my mind, I kinda think that cache experiment should help single or few core applications, eg. games, if they don't dance around too much and stay on the same cores, but I don't know how that's in real life where there are a lot of different processes running at the same time.
So I'm looking forward to even more improvements, but I can imagine that every single improvement on already performant kernel comes with great amount of work.
Big thanks Alfred!
BR, Eduardo
@Eduardo, @Alfred:
DeleteI'm also very-very content with this release, after ~one week in use. I share Eduardo's experience(s) on my 10-years-old Core2Duo, too. And I'm of the same opinion regarding future improvements.
Thumbs up and many thanks to Alfred,
BR, Manuel Krause
@Edurado, @Manuel
DeleteThanks for the feedback. This release seems to be a golden one. So I have to take careful steps in the incoming changes. I am looking into the existed pds code and see what improvement can be made, It's so far so good till now.
Don't pity for the cachehot patch, it just create a short cut in the code path, consider the cost to tell a task is cachehot or not and the reduction of overhead in the exsited code path, it's no point to introduce such short cut. Believe me, you are using the best code in this path currently.
@Alfred, @Eduardo:
DeleteI don't shed any tears over the 'dismissed' cachehot approach. It's just like both of you described/ explained:
In my use, with the cachehot patch, some processes and DE interactions had benefits from it, but I wasn't able to identify what in particular (whether prominent ones like Firefox, Freecad or Libreoffice, window switching or sub-menus in KDE) and based on what pattern.
With this PDS 0.98n, the overhead-cutting and optimizations seem to spread the aforementioned benefits over the entire system's experience. I'm not observing particular bottlenecks or differences in fairness any more.
Only remaining mess occurs when swapping kicks in, but that's not PDS' fault.
BR, Manuel Krause