lkml.org 
[lkml]   [2016]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
    On Mon, 7 Nov 2016 19:49:03 +0100
    Daniel Bristot de Oliveira <daniel@bristot.me> wrote:

    > On 11/07/2016 07:32 PM, Steven Rostedt wrote:
    > >> Excellent this would improve the situation with deadlocks as a result of
    > >> > cgroup_locks not being released due to lack of workqueue processing.
    > > ?? What deadlocks do you see? I mean, can you show the situation that
    > > throttling RT tasks will cause deadlock?
    > >
    > > Sorry, but I'm just not seeing it.
    >
    > It is not a deadlock in the theoretical sense of the word, but it is
    > more a side effect of the starvation - that looks like a deadlock.
    >
    > There is a case where the removal of a cgroup dir calls
    > lru_add_drain_all(), that might schedule a kworker in the CPU that is
    > running the spinning-rt task. The kworker will starve - because they are
    > SCHED_OTHER by design, the lru_add_drain_all() will wait forever while
    > holding the cgroup lock and this will cause a lot of problems on other
    > tasks.

    I understand the issue with not throttling an RT task, but this patch
    is about not not throttling! That is, what scenario is there that will
    cause a "deadlock" or deadlock like to happen when we *do* throttle,
    where not throttling will work better, as this patch would have?

    -- Steve

    \
     
     \ /
      Last update: 2016-11-07 20:18    [W:2.606 / U:0.312 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site