lkml.org 
[lkml]   [2019]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] sched/rt: avoid contend with CFS task
    On 08/29/19 11:38, Valentin Schneider wrote:
    > On 29/08/2019 04:15, Jing-Ting Wu wrote:
    > > At original linux design, RT & CFS scheduler are independent.
    > > Current RT task placement policy will select the first cpu in
    > > lowest_mask, even if the first CPU is running a CFS task.
    > > This may put RT task to a running cpu and let CFS task runnable.
    > >
    > > So we select idle cpu in lowest_mask first to avoid preempting
    > > CFS task.
    > >
    >
    > Regarding the RT & CFS thing, that's working as intended. RT is a whole
    > class above CFS, it shouldn't have to worry about CFS.
    >
    > On the other side of things, CFS does worry about RT. We have the concept
    > of RT-pressure in the CFS scheduler, where RT tasks will reduce a CPU's
    > capacity (see fair.c::scale_rt_capacity()).
    >
    > CPU capacity is looked at on CFS wakeup (see wake_cap() and
    > find_idlest_cpu()), and the periodic load balancer tries to spread load
    > over capacity, so it'll tend to put less things on CPUs that are also
    > running RT tasks.
    >
    > If RT were to start avoiding rqs with CFS tasks, we'd end up with a nasty
    > situation were both are avoiding each other. It's even more striking when
    > you see that RT pressure is done with a rq-wide RT util_avg, which
    > *doesn't* get migrated when a RT task migrates. So if you decide to move
    > a RT task to an idle CPU "B" because CPU "A" had runnable CFS tasks, the
    > CFS scheduler will keep seeing CPU "B" as not significantly RT-pressured
    > while that util_avg signal ramps up, whereas it would correctly see CPU
    > "A" as RT-pressured if the RT task previously ran there.
    >
    > So overall I think this is the wrong approach.

    I like the idea, but yeah tend to agree the current approach might not be
    enough.

    I think the major problem here is that on generic systems where CFS is a first
    class citizen, RT tasks can be hostile to them - not always necessarily for a
    good reason.

    To further complicate the matter, even among CFS tasks we can't tell which are
    more important than the others - though hopefully latency-nice proposal will
    make the situation better.

    So I agree we have a problem here, but I think this patch is just a temporary
    band aid and we need to do better. Though I have no concrete suggestion yet on
    how to do that.

    Another thing I couldn't quantify yet how common and how severe this problem is
    yet. Jing-Ting, if you can share the details of your use case that'd be great.

    Cheers

    --
    Qais Yousef

    \
     
     \ /
      Last update: 2019-08-30 16:56    [W:7.336 / U:0.592 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site