Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1335924 > unrolled thread

[RFC][PATCH] sched: Kick bandwidth timer immediately on start up

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH] sched: Kick bandwidth timer immediately on start up Steven Rostedt <rostedt@goodmis.org> - 2016-02-17 00:40 +0100
    Re: [RFC][PATCH] sched: Kick bandwidth timer immediately on start  up Steven Rostedt <rostedt@goodmis.org> - 2016-02-18 15:20 +0100
      Re: [RFC][PATCH] sched: Kick bandwidth timer immediately on start up Juri Lelli <juri.lelli@arm.com> - 2016-02-19 09:30 +0100

#1335924 — [RFC][PATCH] sched: Kick bandwidth timer immediately on start up

I've been debugging why deadline tasks can cause the RT scheduler to
throttle, even when the deadline tasks are only taking up 50% of the
CPU and RT tasks are not even using 1% of the CPU. Here's what I found.

In order to keep a CPU from being hogged by RT tasks, the deadline
scheduler adds its run time (delta_exec) to the rt_time of the RT
bandwidth. That way, if the two use more than 95% of the CPU within one
second (default settings), the RT tasks are throttled to allow non RT
tasks to run.

Although the deadline tasks add their run time to the RT bandwidth, it
lets the RT tasks do the accounting. This is where the problem lies. If
a deadline task runs for a bit, and no RT tasks are running, then it
will continually add to the RT rt_time that is used to calculate how
much CPU the RT tasks use. But no RT period is in play, and this
accumulation of the runtime never gets reset.

When an RT task finally gets to run, and the watchdog goes off, it can
see that the RT task has used more than it should of, because the
deadline task added all this runtime to its rt_time. Then the RT task
that just woke up gets throttled for no good reason.

I also noticed that when an RT task is queued, it starts the timer to
account for overload and such. But that timer goes off one period
later, which may be too late and the extra rt_time will trigger a
throttle.

This is a quick work around to the problem. When a new RT task is
queued, the bandwidth timer is set to go off immediately. Then the
timer can clear out the extra time added to the rt_time while there was
no RT task running. This stops my tests from triggering the throttle,
and it will still throttle if an RT task runs too much, even while a
deadline task is running.

A better solution may be to subtract the bandwidth that the deadline
task uses from the rt_runtime, and add it back when its finished. Then
there wont be a need for runtime tracking of the time used by deadline
tasks.

I may play with that solution tomorrow.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/sched/rt.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Index: linux-trace.git/kernel/sched/rt.c
===================================================================
--- linux-trace.git.orig/kernel/sched/rt.c	2016-02-16 16:31:12.041035819 -0500
+++ linux-trace.git/kernel/sched/rt.c	2016-02-16 16:31:19.997905282 -0500
@@ -58,7 +58,15 @@ static void start_rt_bandwidth(struct rt
 	raw_spin_lock(&rt_b->rt_runtime_lock);
 	if (!rt_b->rt_period_active) {
 		rt_b->rt_period_active = 1;
-		hrtimer_forward_now(&rt_b->rt_period_timer, rt_b->rt_period);
+		/*
+		 * SCHED_DEADLINE updates the bandwidth, as a run away
+		 * RT task with a DL task could hog a CPU. But DL does
+		 * not reset the period. If a deadline task was running
+		 * without an RT task running, it can cause RT tasks to
+		 * throttle when they start up. Kick the timer right away
+		 * to update the period.
+		 */
+		hrtimer_forward_now(&rt_b->rt_period_timer, ns_to_ktime(0));
 		hrtimer_start_expires(&rt_b->rt_period_timer, HRTIMER_MODE_ABS_PINNED);
 	}
 	raw_spin_unlock(&rt_b->rt_runtime_lock);

[toc] | [next] | [standalone]

#1337384 — Re: [RFC][PATCH] sched: Kick bandwidth timer immediately on start up

On Tue, 16 Feb 2016 18:37:46 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> A better solution may be to subtract the bandwidth that the deadline
> task uses from the rt_runtime, and add it back when its finished. Then
> there wont be a need for runtime tracking of the time used by deadline
> tasks.
> 
> I may play with that solution tomorrow.
> 

OK, so I played with this solution. It's much more complex than I was
hoping it to be. The main issue is there's no one to one relationship
with the deadline bandwidth and the rt bandwidth. Each runqueue has its
own rt ratio, but each root domain that has its own deadline ratio.
Thus, when you add to the dl ratio, it makes adding that to the rt
bandwidths that more complex. It's doable, but it will make getting the
dl_bw right with new root domains harder than it already is, and that
is currently not working.

My recommendation is to hold off on a better solution till we can find a
way to merge rt bandwidth with the Constant Bandwidth Server (CBS).

Thus, please accept this current patch as it appears to fix the problem
without any other side effects that I can find.

-- Steve

[toc] | [prev] | [next] | [standalone]

#1337961

Hi Steve,

On 18/02/16 09:15, Steven Rostedt wrote:
> On Tue, 16 Feb 2016 18:37:46 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > 
> > A better solution may be to subtract the bandwidth that the deadline
> > task uses from the rt_runtime, and add it back when its finished. Then
> > there wont be a need for runtime tracking of the time used by deadline
> > tasks.
> > 
> > I may play with that solution tomorrow.
> > 
> 
> OK, so I played with this solution. It's much more complex than I was
> hoping it to be. The main issue is there's no one to one relationship
> with the deadline bandwidth and the rt bandwidth. Each runqueue has its
> own rt ratio, but each root domain that has its own deadline ratio.
> Thus, when you add to the dl ratio, it makes adding that to the rt
> bandwidths that more complex. It's doable, but it will make getting the
> dl_bw right with new root domains harder than it already is, and that
> is currently not working.
> 
> My recommendation is to hold off on a better solution till we can find a
> way to merge rt bandwidth with the Constant Bandwidth Server (CBS).
> 

I couldn't yet test your change, but it makes sense to me. IIUC, the
work around is only used if an RT task gets enqueued and the rt_period
is not active yet. So, it should fix the over accumulation of rt_time
due to DL and still work for RT, since if a second RT task gets enqueued
when the period is already active it will be eventually throttled when
no more runtime is available.

And yes, we should be able to come up with a better fix once DL will
have groups support. However, since that we'll require some time, I also
think we could work with what you propose for the time being.

Best,

- Juri

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web