What's new
1. Rearrange commits for -test branch work
2. Several minor changes upon 0472, which includes
57374d9 bfs/vrq: Do not need to set_task_cpu() in task_preemptable_rq()
7a1262a bfs/vrq: task_cpu_hotplug() update
cbfc46d bfs/vrq: Deploy cpufreq_trigger() in task_preempt_rq()
7829fd9 bfs/vrq: Add WARN_ON_ONCE() when to_wakeup equal prev
Currently, -test branch rework is on going, hopefully be available at the weekend for testing.
Enjoy it, :)
BR Alfred
@Alfred:
ReplyDeleteIt's up and running fine for some hours now. :-)
@Eduardo & kernelOfTruth:
Would be nice to read your testing results as well.
BR, Manuel Krause
@Alfred:
ReplyDeleteWith all the previous patches I've noticed an increasing cpu utilization with my usage scenario. Mainly depending on firefox' uptime. With this current patch I see a limit for this increase, or at least a significantly lower increase rate, what is very nice. Also, distribution of system and normal prio between my two cpu cores seems to get equalized better.
From your developper's view -- can this be explained with the changes of this VRQ2, or is it more likely to be "fallout" from other possible changes (e.g. Mesa + Intel gfx updates) ? Just like to read your opinion on this.
Now going to the new -test0 version... :-)))
BR, and thank you for all your good work,
Manuel Krause
The commit
Deletecbfc46d bfs/vrq: Deploy cpufreq_trigger() in task_preempt_rq()
would help with cpufreq governor and improve throughput in sanity tests.
Mmmh. I'm using the performance governor all the time. Probably a positive side-effect of something I haven't noticed in detail. This may be even having closed some tabs in FF.
DeleteDon't mind for bothering you, BR
Manuel Krause
FYI:
ReplyDeletethe following occurs with VRQ0, VRQ2:
[ 0.112323] Renew affinity for 14 processes to cpu 1
[ 0.112410] #2
[ 0.175369] Renew affinity for 14 processes to cpu 2
[ 0.175450] #3
[ 0.238417] Renew affinity for 14 processes to cpu 3
[ 0.238498] #4
[ 0.300494] Renew affinity for 14 processes to cpu 4
[ 0.300572] #5
[ 0.362535] Renew affinity for 14 processes to cpu 5
[ 0.362616] #6
[ 0.423524] ------------[ cut here ]------------
[ 0.423546] WARNING: CPU: 2 PID: 24 at arch/x86/kernel/smp.c:125 native_smp_send_reschedule+0x25/0x3b
[ 0.423555] Modules linked in:
[ 0.423565] CPU: 2 PID: 24 Comm: ksoftirqd/2 Not tainted 4.7.1_dtop-I.4 #1
[ 0.423574] Hardware name: [snip]
[ 0.423583] 0000000000000086 00000000a4a20f87 ffff8807fa93bd98 ffffffff81551c6d
[ 0.423593] 0000000000000000 0000000000000000 ffff8807fa93bdd8 ffffffff81124ccc
[ 0.423604] 0000007dffffffff 0000000000000002 0000000000000000 000000000000a138
[ 0.423614] Call Trace:
[ 0.423625] [] dump_stack+0x4d/0x63
[ 0.423636] [] __warn+0xc5/0xe0
[ 0.423645] [] warn_slowpath_null+0x18/0x1a
[ 0.423654] [] native_smp_send_reschedule+0x25/0x3b
[ 0.423664] [] __schedule+0x1e8/0x7bb
[ 0.423674] [] schedule+0x79/0xc1
[ 0.423684] [] smpboot_thread_fn+0x14d/0x1a9
[ 0.423693] [] ? sort_range+0x1d/0x1d
[ 0.423702] [] kthread+0xdc/0xe4
[ 0.423712] [] ret_from_fork+0x1f/0x40
[ 0.423721] [] ? kthread_create_on_node+0x1ac/0x1ac
[ 0.423733] ---[ end trace dd6bfdceedb0dc5f ]---
[ 0.424524] ------------[ cut here ]------------
[ 0.424533] WARNING: CPU: 2 PID: 24 at arch/x86/kernel/smp.c:125 native_smp_send_reschedule+0x25/0x3b
[ 0.424542] Modules linked in:
[ 0.424551] CPU: 2 PID: 24 Comm: ksoftirqd/2 Tainted: G W 4.7.1_dtop-I.4 #1
[ 0.424562] Hardware name: [snip]
[ 0.424572] 0000000000000086 00000000a4a20f87 ffff8807fa93bd98 ffffffff81551c6d
[ 0.424584] 0000000000000000 0000000000000000 ffff8807fa93bdd8 ffffffff81124ccc
[ 0.424592] Renew affinity for 14 processes to cpu 6
[ 0.424603] 0000007dffffffff 0000000000000002 0000000000000000 000000000000a138
[ 0.424610] Call Trace:
[ 0.424617] [] dump_stack+0x4d/0x63
[ 0.424624] [] __warn+0xc5/0xe0
[ 0.424631] [] warn_slowpath_null+0x18/0x1a
[ 0.424638] [] native_smp_send_reschedule+0x25/0x3b
[ 0.424645] [] __schedule+0x1e8/0x7bb
[ 0.424653] #7
[ 0.424653] [] schedule+0x79/0xc1
[ 0.424665] [] smpboot_thread_fn+0x14d/0x1a9
[ 0.424672] [] ? sort_range+0x1d/0x1d
[ 0.424679] [] kthread+0xdc/0xe4
[ 0.424686] [] ret_from_fork+0x1f/0x40
[ 0.424692] [] ? kthread_create_on_node+0x1ac/0x1ac
[ 0.424699] ---[ end trace dd6bfdceedb0dc60 ]---
[ 0.486636] Renew affinity for 14 processes to cpu 7
[ 0.486648] x86: Booted up 1 node, 8 CPUs
[ 0.486655] smpboot: Total of 8 processors activated (54306.10 BogoMIPS)
7a1262a bfs/vrq: task_cpu_hotplug() update
Deletein VRQ2 should fixed this by just allowed online cpus in the tsk_allowed_cpumask, would you double check it again?
BR Alfred
I compiled a new kernel with 4.7.2 (merging 4.7.2 into 4.7.1),
Deleteand the error message didn't occur on this boot,
will observe if it shows again on the next boot ups.
So far, so good
Thank you :)
I don't know, Alfred if it's VRQ2 compared to VRQ0
ReplyDeletebut there's lots of stuttering during mpv playback when e.g. HQ (1080p) videos are played back at 60 or 48 fps,
I've meanwhile also updated vapoursynth and mpv so I'm not really sure if it's BFS or mpv and vapoursynth that are causing trouble,
and nvidia-drivers also were updated - are there any known issues with 370.23 ?
In the past this was really smooth.
Even when disabling compositing for kwin it occurs
>is the introduction of preempt stick task to replace the original stick timeout in previous release, which helps with high workload performance and the result can be proved in the sanity test report.
sounds VRQ3 could help ...
Thanks
I should have written it more clearly, sorry
Deletethe issue didn't occur with a Kernel which had vrq0,
but now it occurs on a kernel which is using vrq2
Thanks
@kernelOfTruth
DeleteWould you try the all-in-one patch file of vrq1, it should fix a suspend/resume issue on vrq0 and there are just 4 commits different between vrq1 and vrq2.