From: Peter Zijlstra <peterz@infradead.org>
To: Raistlin <raistlin@linux.it>
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: Re: [RFC][PATCH 02/11] sched: SCHED_DEADLINE policy implementation.
Date: Tue, 13 Apr 2010 20:22:15 +0200 [thread overview]
Message-ID: <1271182935.4807.1876.camel@twins> (raw)
In-Reply-To: <1267384639.13676.87.camel@Palantir>
On Sun, 2010-02-28 at 20:17 +0100, Raistlin wrote:
> +/*
> + * Pure Earliest Deadline First (EDF) scheduling does not deal with the
> + * possibility of a task lasting more than what it declared, and thus
> + * exhausting its runtime.
> + *
> + * Here we are interested in making runtime overrun possible, but we do
> + * not want a task which is misbehaving to affect the scheduling of all
> + * other tasks.
> + * Therefore, a budgeting strategy called Constant Bandwidth Server (CBS)
> + * is used, in order to confine each task within its own bandwidth.
> + *
> + * This function deals exactly with that, and ensures that when the runtime
> + * of a task is replenished, its deadline is also postponed. That results
> + * in "priority unboosting" for the overrunning task, and makes it impossible
> + * for it to cause unexpected interfere to other tasks in the system.
> + */
This is not about lock/inheritance related overrun, right? But simply a
task that got its WCET wrong.
next prev parent reply other threads:[~2010-04-13 18:22 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 [this message]
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-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 ` [RFC][PATCH 08/11] sched: send SIGXCPU at -deadline task overruns Raistlin
2010-04-13 18:22 ` 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=1271182935.4807.1876.camel@twins \
--to=peterz@infradead.org \
--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=raistlin@linux.it \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.