-
Notifications
You must be signed in to change notification settings - Fork 12
Global runqueue #12
Comments
Hi @hamadmarri, I am testing with the latest commit (as the time of writing). So far I have found:
|
Hi @raykzhao Sorry, I forgot to mention that it only works on Thank you for testing 👍 |
not stable 👎 I got freezes. I am trying on RT kernel which shows the freezes right after the boot. Also for RT I need to use |
I am going to use global rq points to the rq of cpu0, as the convention used in MuQSS. Although the separate lock is very lightweight since it is only locked in very critical sections but it is unstable and the scheduler depends on the stats of each rq in almost everywhere. This adjustments (if it worked correctly) will reduce the performance a bit, but then I will look at and remove some useless migrations (from global rq perspective) which can reduce the locking contentions. |
Another idea which is stable: Candidate Balancer (CB). Each rq propose candidate task which has the highest HRRN. It is somehow similar to RDB but it is mixed with the normal TT basic balancer (which is based on number of tasks). CPUs will try to pull a candidate task (if it has higher hrrn), if no candidate -for idle cpus- it will just pull a task from a cpu that has maximum number of tasks as usual TT balancer does. The TT balancer acts like a fallback balancer in case no provided candidates. The candidate cannot be a cpu bound task or kthread. I am testing it right now on RT kernel. Both throughput and the latency are better. Here are two patches: Non-RT: should be patched on top of tt. Thank you |
Hi @hamadmarri
|
I reverted the commits here you can just comment the line out, the wake affain weight show worse results in my case |
This is a guaranteed stable GRQ implementation. Works on top of TT and TT-rt I used first cpu to be the global rq, to check:
Please test. I am going to make both candidate and grq as optional for TT v0.3. So far I got the highest stress-ng results on GRQ Thank you |
GRQ update: https://github.com/hamadmarri/TT-CPU-Scheduler/releases/tag/0.3.1 Now it is better with both nohz full/idle I also fixed some bugs for non-idle cpu balancing with GRQ. Thank you |
Obviously. GRQ in v0.3.1 is better than v0.3 in my case Both in terms of latency and throughput |
GRQ updated to v0.3.2: Bench with python responsive script: |
It seems the GRQ cheduler is very bad for performance. Enabling it halfs my fps. |
Branch: https://github.com/hamadmarri/linux-baby/tree/tt-grq
Welcome back to GRQ again. I still have some hope to implement global runqueue
on current CFS. It is not an easy task apparently. I have reimplemented the
old GRQ with slight modification. Don't use this commit
385bff302e395a88306fba3823c21d231c8c31f2
since it freezes like the old GRQ implementation on Cachy/CacULE.
However, in
11962a4e7cc20dd5fa9539d88c7a884b93995301
is a try to fix freezing issue. I am testing it right now, but as usual whenever I believe it is fixed it will surprise me with a freeze at random time/day! But so far no freezes yet.If you want to test, make sure that you don't have any important files on your computer since the GRQ freezes can cause damage to FS. Also, don't use GRQ while your are doing important tasks
Please let me know if you got any freezes with this commit and later
11962a4e7cc20dd5fa9539d88c7a884b93995301
and whether it has better performance/latencyThank you
The text was updated successfully, but these errors were encountered: