v4.7_0472_test1 patch released
v4.7_0472_test1 patch is released. In this release
1. Improve throughput performance by introducing cpu affinity selection in pick_other_cpu_stick_task() . This helps to reduce regression on SMT cpus.
2. Immediately select preempt task in deactivate_choose_task(). This helps with performance, for interactivity, I'd need your comments to find out.
Enjoy it and I am looking at the debug patches in 4.6 release, -test2 patch will be out next week, :)
BR Alfred
Hey,
ReplyDeleteI accidentally came across your kernel patches and I actually couldn't find general information about this patch (Just that it is based on bfs). Could you quickly summarize the features of the vrq-patchset?
Thanks :)
It seems that it's time to write the f**k document, :)
DeleteOk, in short, the major features upon bfs are list below
1. Sync-up with mainline kernel scheduler which not picked by BFS
2. Full cpumask cpu selection
3. VRQ locking strategy to reduce global run queue locking in BFS
4. Preempt task solution which add a quick path to pass task to cpu/rq instead using grq
5. Task stick&caching mechanism to improve performance.
BR Alfred
Thank you for this short summary. Although I'm not the author of the question above, your information is quite valuable to argue with my friends, why I spend so much time with testing your patches(!) :-)
DeleteAs they still don't understand anything, I can only encourage you to furtherly enrich your feature list by explaining the positive results in detail, what users would/should/can expect by using your VRQ's features.
BR, Manuel Krause
@Alfred:
ReplyDeleteIt's running o.k. so far, but... I have no idea, whether this info is helpful: Sometimes, when the mouse pointer was idle for some time, I notice a very little lag when moving it again. It's very slight, but noticeable. In my experience, I cannot pin it down to higher i/o or such, it seeems to depend on the idle period.
The -test0 and pure VRQ2 haven't shown this behaviour.
Best regards,
Manuel Krause
@Manuel
DeleteApply the below patch upon -test1 and see how it goes?
diff --git a/kernel/sched/bfs.c b/kernel/sched/bfs.c
index cf15aff..7a9e838 100644
--- a/kernel/sched/bfs.c
+++ b/kernel/sched/bfs.c
@@ -4000,7 +4000,12 @@ deactivate_choose_task##subfix(struct rq *rq,\
next = rq->preempt_task;\
if (next) {\
take_preempt_task((rq), next);\
- goto unlock_out;\
+ if (next->priodl < prev->priodl)\
+ goto unlock_out;\
+ /* put preemt task(now the next) back to grq */\
+ enqueue_task(next, rq);\
+ inc_qnr();\
+ next->on_cpu = NOT_ON_CPU;\
}\
DEACTIVATE_NO_DEDICATED_TASK_HANDLE##subfix;\
\
I assume THIS has nothing to do with the THREE posted debug patches some minutes ago?
DeleteI'd try this one first.
Holy weekend... ;-)
Thank you for your work and more than BR as ever,
Manuel Krause
This patch moderates the issue, but doesn't solve it. Previously I got several micro stutterers with the pointer movement after it being idle, now I get a shorter one coming up with video and audio playback blackout for a very short amount of time -- lower period than my original issue with the pointer, but still noticeable -- and not wishful.
DeleteIs it allowed to keep it when testing the three DEBUG patches -- or would this confuse the testing?
BR, Manuel Krause
@Manuel
DeleteHow does it(with this reverse patch) comparing to the -test0 one?
As there is only two commits added upon -test0 and this is one reversed, I'd like to find out if another one also impacted or any improvement needed.
I was not 100% clear what you meant with the first sentence/question.
DeleteAssuming, you wanted me to cross check -test1 with the little diff above applied vs. the -test0 with it reverted, I've setup the -test0 kernel this way. Result is: NO lagging pointer after it having been idle.
After having a short look into the difference between -test0 and -test1, I want to add the following additional info, maybe it helps to look for the right code section:
In my .config I have:
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
and so CONFIG_SMT_NICE is silently by default also OFF.
Maybe this helps, good luck and BR,
Manuel Krause
O.k. At this moment I'd need to correct my statement above, that there is NO lagging pointer with the above setup.
DeleteI also get lags, but they appear much later in mouse idle time, than with -test1 & -test1+applied diff.
Does this make any sense to you? An idea? Would you suggest that I retest backwards? Maybe I've missed something in within the transition from plain VRQ2 to -test0 (or even earlier).
BR, Manuel Krause
Oh, forgotten to add this:
DeleteWith the reverted diff at -test0, behaviour is almost like with -test1 +applied diff: meaning "shorter lag coming up with video and audio playback blackout for a very short amount of time" -- only pointer lagging period is much shorter and time to hit it is much longer. So it's not as easily to notice on here with -test0 than with -test1.
BR, Manuel Krause
en...it's enough confusing, I will release -test2 today. :D
DeleteHi,
ReplyDeleteI gave test1 a try, on an intel quad core smt CPU and AMD quad core _non_ smt CPU, it behaves ok. No lagging mouse or the like.
I played some old (2011) games via G9 and there seems to be no lag at all.
As I'm not feeling well, I didn't try any other, let's say, usual set of games, so I can't confirm nor deny about stutter in games, yet.
I'll follow what's happening here and will come up with the results eventually.
br,
Eduardo
@Edurado
DeleteTake care yourself. -test2 has been released and it should be a better version. Give it a try when your time available.
@Eduardo:
DeleteYour health is the most important! I wish that you'll recover well.
(So that you can join the debug patches' puzzle game, soon. ;-) ) Just kidding a little. Have a good recreation!
Addon: The -test2 version is really a good one to use. Give it a try, if you find time.
BR, Manuel Krause