linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Raistlin <raistlin@linux.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Chris Friesen <cfriesen@nortel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Darren Hart <darren@dvhart.com>, Henrik Austad <henrik@austad.us>,
	Johan Eker <johan.eker@ericsson.com>,
	"p.faure" <p.faure@akatech.ch>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Claudio Scordino <claudio@evidence.eu.com>,
	michael trimarchi <trimarchi@retis.sssup.it>,
	Fabio Checconi <fabio@gandalf.sssup.it>,
	Tommaso Cucinotta <t.cucinotta@sssup.it>,
	Juri Lelli <juri.lelli@gmail.com>,
	Nicola Manica <nicola.manica@gmail.com>,
	Luca Abeni <luca.abeni@unitn.it>
Subject: [RFC][PATCH 08/11] sched: send SIGXCPU at -deadline task overruns.
Date: Sun, 28 Feb 2010 20:24:06 +0100	[thread overview]
Message-ID: <1267385046.13676.97.camel@Palantir> (raw)
In-Reply-To: <1267383976.13676.79.camel@Palantir>

[-- Attachment #1: Type: text/plain, Size: 5095 bytes --]

Add to the scheduler the capability of notifying when -deadline tasks
overrun their maximum runtime and/or overcome their scheduling
deadline.

Runtime overruns might be quite common, e.g., due to coarse granularity
execution time accounting resolution or wrong assignment of tasks'
parameters (especially runtime). However, since the scheduler enforces
bandwidth isolation among tasks, this is not at all a threat to other
tasks' schedulability. For this reason, it is not common that a task
wants to be notified about that. Moreover, if we are using the
SCHED_DEADLINE policy with sporadic tasks, or to limit the bandwidth
of not periodic nor sporadic ones, runtime overruns are very likely
to occur at each and every instance, and again they should not be
considered a problem.

On the other hand, a deadline miss in any task means that, even if we
are trying at our best to keep each task isolated and to avoid
reciprocal interference among them, something went very, very bad,
and one task did not manage in consuming its runtime by its deadline.
This is something that should happen only on an oversubscribed
system, and thus being notified when it occurs could be very useful.

The user can specify the signals he wants to be sent to his task
during sched_setscheduler_ex(), raising two specific flags in the
sched_flags field of struct sched_param_ex:
 * SCHED_SIG_RORUN (if he wants to be signaled on runtime overrun),
 * SCHED_SIG_DMISS (if he wants to be signaled on deadline misses).

This patch:
 - adds the logic needed to send SIGXCPU signal to a -deadline task
   in case its actual runtime becomes negative;
 - adds the logic needed to send SIGXCPU signal to a -deadline task
   in case it is still being scheduled while its absolute deadline
   passes.

Signed-off-by: Dario Faggioli <raistlin@linux.it>
---
 include/linux/sched.h |   18 ++++++++++++++++++
 kernel/sched_dl.c     |   24 ++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index e6c1cda..64a7df2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -138,6 +138,7 @@ struct sched_param {
  * More information about the algorithm are available in the scheduling
  * class file or in Documentation/.
  */
+
 struct sched_param_ex {
 	int sched_priority;
 	struct timespec sched_runtime;
@@ -146,6 +147,23 @@ struct sched_param_ex {
 	unsigned int sched_flags;
 };
 
+/*
+ * User -deadline flags.
+ *
+ * These flags are exported to userspace so that tasks can try to affect
+ * the scheduler behaviour and/or specifying that they want to be informed
+ * of the occurrence of some events. There are at most 16 of them available
+ * (lowest bits), since values above 0x10000 are reserved for kernel
+ * internal flags.
+ *
+ *  @SCHED_SIG_RORUN	tells us the task wants to be notified whenever
+ *                      a runtime overrun occurs;
+ *  @SCHED_SIG_DMISS	tells us the task wants to be notified whenever
+ *                      a scheduling deadline is missed.
+ */
+#define SCHED_SIG_RORUN		0x0001
+#define SCHED_SIG_DMISS		0x0002
+
 struct exec_domain;
 struct futex_pi_state;
 struct robust_list_head;
diff --git a/kernel/sched_dl.c b/kernel/sched_dl.c
index dee2668..b5dde44 100644
--- a/kernel/sched_dl.c
+++ b/kernel/sched_dl.c
@@ -265,6 +265,14 @@ static void init_dl_timer(struct sched_dl_entity *dl_se)
 	timer->function = dl_timer;
 }
 
+#define dl_se_signal(se, s, msg)					\
+ do {									\
+  struct task_struct *t = dl_task_of(se);				\
+  sigaddset(&t->pending.signal, s);					\
+  set_tsk_thread_flag(t, TIF_SIGPENDING);				\
+  printk(KERN_INFO msg "in %d (%s)\n", task_pid_nr(t), t->comm);	\
+ } while (0)
+
 static
 int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
 {
@@ -283,6 +291,22 @@ int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
 	if (dmiss)
 		dl_se->runtime -= rq->clock - dl_se->deadline;
 
+	/*
+	 * if the userspace asked for that, we notify about (scheduling)
+	 * deadline misses and runtime overruns via sending SIGXCPU to
+	 * "faulting" task.
+	 *
+	 * Note that (hopefully small) runtime overruns are very likely
+	 * to occur, mainly due to accounting resolution, while missing a
+	 * scheduling deadline should be very rare, and only happen on
+	 * an oversubscribed systems.
+	 */
+	if (unlikely(dmiss && dl_se->flags & SCHED_SIG_DMISS))
+		dl_se_signal(dl_se, SIGXCPU, "Deadline miss");
+
+	if (unlikely(rorun && dl_se->flags & SCHED_SIG_RORUN))
+		dl_se_signal(dl_se, SIGXCPU, "Runtime overrun");
+
 	dequeue_dl_entity(dl_se);
 	if (!start_dl_timer(dl_se, dl_se->deadline)) {
 		if (!rorun)
-- 
1.7.0

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2010-02-28 19:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28 19:06 [RFC][PATCH 0/11] sched: SCHED_DEADLINE v2 Raistlin
2010-02-28 19:15 ` [RFC][PATCH 01/11] sched: add sched_class->task_dead Raistlin
2010-02-28 19:17 ` [RFC][PATCH 02/11] sched: SCHED_DEADLINE policy implementation Raistlin
2010-04-13 18:22   ` Peter Zijlstra
2010-04-13 18:22   ` Peter Zijlstra
2010-04-13 18:22   ` Peter Zijlstra
2010-04-13 18:55     ` Steven Rostedt
2010-04-15  7:34       ` Peter Zijlstra
2010-04-13 18:22   ` Peter Zijlstra
2010-04-13 18:22   ` Peter Zijlstra
2010-02-28 19:18 ` [RFC][PATCH 03/11] sched: add extended scheduling interface Raistlin
2010-02-28 19:19 ` [RFC][PATCH 04/11] sched: add resource limits for -deadline tasks Raistlin
2010-02-28 19:20 ` [RFC][PATCH 05/11] sched: add a syscall to wait for the next instance Raistlin
2010-02-28 19:22 ` [RFC][PATCH 06/11] sched: add the sched-debug bits for sched_dl Raistlin
2010-02-28 19:23 ` [RFC][PATCH 07/11] sched: add latency tracing for -deadline tasks Raistlin
2010-02-28 19:24 ` Raistlin [this message]
2010-04-13 18:22   ` [RFC][PATCH 08/11] sched: send SIGXCPU at -deadline task overruns Peter Zijlstra
2010-04-13 19:32     ` Oleg Nesterov
2010-02-28 19:26 ` [RFC][PATCH 09/11] sched: first draft of deadline inheritance Raistlin
2010-04-14  8:25   ` Peter Zijlstra
2010-04-14  9:45     ` Peter Zijlstra
2010-02-28 19:27 ` [RFC][PATCH 10/11] sched: add bandwidth management for sched_dl Raistlin
2010-04-14 10:09   ` Peter Zijlstra
2010-02-28 19:28 ` [RFC][PATCH 11/11] sched: add sched_dl documentation Raistlin
2010-04-14 10:17 ` [RFC][PATCH 0/11] sched: SCHED_DEADLINE v2 Peter Zijlstra

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=1267385046.13676.97.camel@Palantir \
    --to=raistlin@linux.it \
    --cc=cfriesen@nortel.com \
    --cc=claudio@evidence.eu.com \
    --cc=darren@dvhart.com \
    --cc=fabio@gandalf.sssup.it \
    --cc=fweisbec@gmail.com \
    --cc=henrik@austad.us \
    --cc=johan.eker@ericsson.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@unitn.it \
    --cc=mingo@elte.hu \
    --cc=nicola.manica@gmail.com \
    --cc=p.faure@akatech.ch \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=t.cucinotta@sssup.it \
    --cc=tglx@linutronix.de \
    --cc=trimarchi@retis.sssup.it \
    /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;
as well as URLs for NNTP newsgroup(s).