lkml.org 
[lkml]   [2019]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH v3 00/16] Core scheduling v3
    >
    > What accounting in particular is upset? Is it things like
    > select_idle_sibling() that thinks the thread is idle and tries to place
    > tasks there?
    >
    The major issue that we saw was, certain work load causes the idle cpu to never
    wakeup and schedule again even when there are runnable threads in there. If
    I remember correctly, this happened when the sibling had only one cpu intensive
    task and did not enter the pick_next_task for a long time. There were other
    situations as well which caused this prolonged idle state on the cpu.
    One was when
    pick_next_task was called on the sibling but it always won there
    because vruntime
    was not progressing on the idle cpu.

    Having a coresched idle makes sure that the idle thread is not overloaded. Also
    vruntime moves forward and tsk vruntime comparison across cpus works when
    we normalize.

    > It should be possible to change idle_cpu() to not report a forced-idle
    > CPU as idle.
    I agree. If we can identify all the places the idle thread is
    considered special and
    also account for the vruntime progress for force idle, this should be a better
    approach compared to coresched idle thread per cpu.

    >
    > (also; it should be possible to optimize select_idle_sibling() for the
    > core-sched case specifically)
    >
    We haven't seen this because, most of our micro test cases did not have more
    threads than the cpus. Thanks for pointing this out, we shall cook some tests
    to observe this behavior.

    Thanks,
    Vineeth

    \
     
     \ /
      Last update: 2019-08-06 17:54    [W:3.319 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site