lkml.org 
[lkml]   [2017]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.
    From
    Date
    On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote:
    > Hello, Atish, Peter, all.
    >
    > I have a question about if a task's nr_cpus_allowed is 1.
    > In that scenario we do not call select_task_rq. Therefore
    > even thought a task "p" is placed on idle CPU that CPU
    > will not be marked as claimed for wake-up.
    >
    > What do you think about adding per_cpu(claim_wakeup, cpu) = 1;
    > to select_task_rq() instead and possibly get rid of them from
    > other places (increases a race window a bit)?

    My thoughts on all of this is that we need less SIS, not more.  Rather
    than trying so hard for the absolute lowest wakeup latency, which
    induces throughput/efficiency robbing bouncing, I think we'd be better
    of considering leaving an already llc affine task where it is if the
    average cycle time is sufficiently low that it will likely hit the CPU
    RSN.  Completely ignoring low utilization kernel threads would go a
    long way to getting rid of bouncing userspace (which tends to have a
    meaningful footprint), all over hell and creation.

    You could also periodically send mobile kthreads down the slow path to
    try to keep them the hell away from partially busy CPUs, as well as
    anything else that hasn't run for a while, to keep background cruft
    from continually injecting itself into the middle of a cross core
    cyber-sex.

    -Mike

    \
     
     \ /
      Last update: 2017-11-23 14:15    [W:5.517 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site