Tuesday, August 9, 2016

v4.7_0472_vrq2 patch released

v4.7_0472_vrq2 patch was released at bitbucket and github.

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

10 comments:

  1. @Alfred:
    It's up and running fine for some hours now. :-)

    @Eduardo & kernelOfTruth:
    Would be nice to read your testing results as well.

    BR, Manuel Krause

    ReplyDelete
  2. @Alfred:
    With 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

    ReplyDelete
    Replies
    1. The commit
      cbfc46d bfs/vrq: Deploy cpufreq_trigger() in task_preempt_rq()
      would help with cpufreq governor and improve throughput in sanity tests.

      Delete
    2. 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.

      Don't mind for bothering you, BR
      Manuel Krause

      Delete
  3. FYI:

    the 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)

    ReplyDelete
    Replies
    1. 7a1262a bfs/vrq: task_cpu_hotplug() update
      in VRQ2 should fixed this by just allowed online cpus in the tsk_allowed_cpumask, would you double check it again?

      BR Alfred

      Delete
    2. I compiled a new kernel with 4.7.2 (merging 4.7.2 into 4.7.1),

      and 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 :)

      Delete
  4. I don't know, Alfred if it's VRQ2 compared to VRQ0

    but 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

    ReplyDelete
    Replies
    1. I should have written it more clearly, sorry

      the issue didn't occur with a Kernel which had vrq0,

      but now it occurs on a kernel which is using vrq2

      Thanks

      Delete
    2. @kernelOfTruth
      Would 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.

      Delete