mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "tip-bot for Steven Rostedt (VMware)" <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: romulo.deoliveira@ufsc.br, juri.lelli@arm.com, efault@gmx.de,
	luca.abeni@santannapisa.it, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	bristot@redhat.com, tommaso.cucinotta@sssup.it, hpa@zytor.com,
	torvalds@linux-foundation.org, rostedt@goodmis.org,
	mingo@kernel.org
Subject: [tip:sched/core] sched/deadline: Use deadline instead of period when calculating overflow
Date: Thu, 16 Mar 2017 04:16:17 -0700	[thread overview]
Message-ID: <tip-2317d5f1c34913bac5971d93d69fb6c31bb74670@git.kernel.org> (raw)
In-Reply-To: <02135a27f1ae3fe5fd032568a5a2f370e190e8d7.1488392936.git.bristot@redhat.com>

Commit-ID:  2317d5f1c34913bac5971d93d69fb6c31bb74670
Gitweb:     http://git.kernel.org/tip/2317d5f1c34913bac5971d93d69fb6c31bb74670
Author:     Steven Rostedt (VMware) <rostedt@goodmis.org>
AuthorDate: Thu, 2 Mar 2017 15:10:59 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 16 Mar 2017 09:37:38 +0100

sched/deadline: Use deadline instead of period when calculating overflow

I was testing Daniel's changes with his test case, and tweaked it a
little. Instead of having the runtime equal to the deadline, I
increased the deadline ten fold.

Daniel's test case had:

	attr.sched_runtime  = 2 * 1000 * 1000;		/* 2 ms */
	attr.sched_deadline = 2 * 1000 * 1000;		/* 2 ms */
	attr.sched_period   = 2 * 1000 * 1000 * 1000;	/* 2 s */

To make it more interesting, I changed it to:

	attr.sched_runtime  =  2 * 1000 * 1000;		/* 2 ms */
	attr.sched_deadline = 20 * 1000 * 1000;		/* 20 ms */
	attr.sched_period   =  2 * 1000 * 1000 * 1000;	/* 2 s */

The results were rather surprising. The behavior that Daniel's patch
was fixing came back. The task started using much more than .1% of the
CPU. More like 20%.

Looking into this I found that it was due to the dl_entity_overflow()
constantly returning true. That's because it uses the relative period
against relative runtime vs the absolute deadline against absolute
runtime.

  runtime / (deadline - t) > dl_runtime / dl_period

There's even a comment mentioning this, and saying that when relative
deadline equals relative period, that the equation is the same as using
deadline instead of period. That comment is backwards! What we really
want is:

  runtime / (deadline - t) > dl_runtime / dl_deadline

We care about if the runtime can make its deadline, not its period. And
then we can say "when the deadline equals the period, the equation is
the same as using dl_period instead of dl_deadline".

After correcting this, now when the task gets enqueued, it can throttle
correctly, and Daniel's fix to the throttling of sleeping deadline
tasks works even when the runtime and deadline are not the same.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Juri Lelli <juri.lelli@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luca Abeni <luca.abeni@santannapisa.it>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Romulo Silva de Oliveira <romulo.deoliveira@ufsc.br>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.1488392936.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/deadline.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 736d8b9..a2ce590 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -445,13 +445,13 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se,
  *
  * This function returns true if:
  *
- *   runtime / (deadline - t) > dl_runtime / dl_period ,
+ *   runtime / (deadline - t) > dl_runtime / dl_deadline ,
  *
  * IOW we can't recycle current parameters.
  *
- * Notice that the bandwidth check is done against the period. For
+ * Notice that the bandwidth check is done against the deadline. For
  * task with deadline equal to period this is the same of using
- * dl_deadline instead of dl_period in the equation above.
+ * dl_period instead of dl_deadline in the equation above.
  */
 static bool dl_entity_overflow(struct sched_dl_entity *dl_se,
 			       struct sched_dl_entity *pi_se, u64 t)
@@ -476,7 +476,7 @@ static bool dl_entity_overflow(struct sched_dl_entity *dl_se,
 	 * of anything below microseconds resolution is actually fiction
 	 * (but still we want to give the user that illusion >;).
 	 */
-	left = (pi_se->dl_period >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
+	left = (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
 	right = ((dl_se->deadline - t) >> DL_SCALE) *
 		(pi_se->dl_runtime >> DL_SCALE);
 

  parent reply	other threads:[~2017-03-16 11:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 14:10 [PATCH V4 0/3] sched/deadline: Fixes for constrained deadline tasks Daniel Bristot de Oliveira
2017-03-02 14:10 ` [PATCH V4 1/3] sched/deadline: Replenishment timer should fire in the next period Daniel Bristot de Oliveira
2017-03-07  7:51   ` Wanpeng Li
2017-03-16 11:15   ` [tip:sched/core] sched/deadline: Make sure the replenishment timer fires " tip-bot for Daniel Bristot de Oliveira
2017-03-02 14:10 ` [PATCH V4 2/3] sched/deadline: Throttle a constrained deadline task activated after the deadline Daniel Bristot de Oliveira
2017-03-06 15:51   ` Luca Abeni
2017-03-07  7:52   ` Wanpeng Li
2017-03-16 11:15   ` [tip:sched/core] " tip-bot for Daniel Bristot de Oliveira
2017-03-02 14:10 ` [PATCH V4 3/3] sched/deadline: Use deadline instead of period when calculating overflow Daniel Bristot de Oliveira
2017-03-07  7:53   ` Wanpeng Li
2017-03-16 11:16   ` tip-bot for Steven Rostedt (VMware) [this message]
2017-03-15 16:18 ` [PATCH V4 0/3] sched/deadline: Fixes for constrained deadline tasks Daniel Bristot de Oliveira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tip-2317d5f1c34913bac5971d93d69fb6c31bb74670@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bristot@redhat.com \
    --cc=efault@gmx.de \
    --cc=hpa@zytor.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=romulo.deoliveira@ufsc.br \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tommaso.cucinotta@sssup.it \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome