Re: [PATCH] sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Fri, 2008-10-03 at 17:40 +0200, Dario Faggioli wrote:
> > Hi all,
> > 
> > While working on the new version of the code for SCHED_SPORADIC I
> > noticed something strange in the present throttling mechanism. More
> > specifically in the throttling timer handler in sched_rt.c
> > (do_sched_rt_period_timer()) and in rt_rq_enqueue().
> > 
> > The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
> > asks for rescheduling if the runqueue has a sched_entity associated to
> > it (i.e., rt_rq->rt_se != NULL).
> > Now, if the runqueue is the root rq (which has a rt_se = NULL)
> > rescheduling does not take place, and it is delayed to some undefined
> > instant in the future.
> > 
> > This imply some random bandwidth usage by the RT tasks under throttling.
> > For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
> > task will get less than 95%. In our tests we got something varying
> > between 70% to 95%.
> > Using smaller time values, e.g., 95ms/100ms, things are even worse, and
> > I can see values also going down to 20-25%!!
> > 
> > The tests we performed are simply running 'yes' as a SCHED_FIFO task,
> > and checking the CPU usage with top, but we can investigate thoroughly
> > if you think it is needed.
> > 
> > Things go much better, for us, with the attached patch... Don't know if
> > it is the best approach, but it solved the issue for us.
> 
> Its consistent with John Blackwood's change to the !group case
> (f3ade837), and looks good.
> 
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> 
> Ingo, please pickup (might be 27.1 material as well).

applied to tip/sched/devel, thanks! I've also added a Cc: 
stable@kernel.org tag to the commit.

	Ingo