From: Raistlin <raistlin@linux.it>
To: Ted Baker <baker@cs.fsu.edu>
Cc: Henrik Austad <henrik@austad.us>,
Chris Friesen <cfriesen@nortel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Douglas Niehaus <niehaus@ittc.ku.edu>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Bill Huey <billh@gnuppy.monkey.org>,
Linux RT <linux-rt-users@vger.kernel.org>,
Fabio Checconi <fabio@gandalf.sssup.it>,
"James H. Anderson" <anderson@cs.unc.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Dhaval Giani <dhaval.giani@gmail.com>,
Noah Watkins <jayhawk@soe.ucsc.edu>,
KUSP Google Group <kusp@googlegroups.com>,
Tommaso Cucinotta <cucinotta@sssup.it>,
Giuseppe Lipari <lipari@retis.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel
Date: Fri, 17 Jul 2009 02:19:37 +0200 [thread overview]
Message-ID: <1247789977.4929.147.camel@Palantir> (raw)
In-Reply-To: <20090716231323.GE27757@cs.fsu.edu>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
On Thu, 2009-07-16 at 19:13 -0400, Ted Baker wrote:
> To be sure we are using A and B the same way here:
> B is holding a lock.
> A wants that lock.
> A grants its priority B until B releases the lock.
>
> How to look at the charges for usage seems not to have a perfect
> solution. That is, you can't get around the fact that either:
>
> [...]
>
> The right way to resolve this conflict seems to depend a lot on
> where B runs, as well as whether you are managing budget per-CPU
> (partitioned model) or managing it globally (free migration
> model).
>
> 1) In a global scheduling model, it does not matter where B runs.
> We want to charge B's critical section to B, since our
> schedulability analysis is based on the processor usage of each
> task. It would be broken if A could be charged random bits of
> time for the execution of other tasks. So, we must charge B.
>
Mmm... Why can't we make B able to exploit A's bandwidth to speed up
critical section completion, to the benefit of A as well? I mean, it
depends on how analysis is being carried out, and it is probably good or
bad depending on what you care most, e.g., making all task's deadline or
isolating the various components between each other... But I wouldn't
say it is "broken".
Especially because I implemented it once... Very rough, very
experimental, far from being ready for anything different than some
experiments... But it worked! :-)
> 2) In a partitioned scheuling model, we worry about the
> CPU utilization of each processor. We have several cases, depending
> where B runs when it runs with A's priority:
>
Ok, I'm not going into this, since I need a little bit more time to
figure out the details... I'm concentrating on global scheduling for
now! :-D
Regards,
Dario
--
<<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 --]
next prev parent reply other threads:[~2009-07-17 0:19 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-10 21:50 RFC for a new Scheduling policy/class in the Linux-kernel Henrik Austad
2009-07-11 18:28 ` Peter Zijlstra
2009-07-12 2:40 ` Douglas Niehaus
2009-07-12 15:31 ` Peter Zijlstra
2009-07-13 15:44 ` Raistlin
2009-07-13 16:33 ` Chris Friesen
2009-07-14 10:47 ` Raistlin
2009-07-14 11:03 ` Peter Zijlstra
2009-07-14 18:19 ` Raistlin
2009-07-14 14:48 ` Chris Friesen
2009-07-14 15:19 ` James H. Anderson
2009-07-14 16:31 ` Peter Zijlstra
2009-07-14 16:54 ` James H. Anderson
2009-07-14 19:28 ` Henrik Austad
2009-07-14 19:33 ` James H. Anderson
2009-07-15 21:53 ` Ted Baker
2009-07-17 7:40 ` Henrik Austad
2009-07-17 13:37 ` Ted Baker
2009-07-15 4:25 ` Bjoern B. Brandenburg
2009-07-15 20:55 ` Ted Baker
2009-07-15 21:53 ` Chris Friesen
2009-07-15 22:34 ` Ted Baker
2009-07-15 22:39 ` Dhaval Giani
2009-07-15 23:16 ` Ted Baker
2009-07-16 8:58 ` Peter Zijlstra
2009-07-16 9:11 ` Peter Zijlstra
2009-07-17 0:32 ` Raistlin
2009-07-17 0:43 ` Raistlin
2009-07-16 12:17 ` Raistlin
2009-07-16 23:29 ` Raistlin
2009-07-18 20:12 ` Michal Sojka
2009-07-14 17:16 ` James H. Anderson
2009-07-15 21:19 ` Ted Baker
2009-07-14 19:54 ` Raistlin
2009-07-14 16:48 ` Raistlin
2009-07-14 18:24 ` Chris Friesen
2009-07-14 19:14 ` Raistlin
2009-07-15 22:14 ` Ted Baker
2009-07-16 7:17 ` Henrik Austad
2009-07-16 23:13 ` Ted Baker
2009-07-17 0:19 ` Raistlin [this message]
2009-07-17 7:31 ` Henrik Austad
2009-07-16 14:46 ` Chris Friesen
2009-07-16 22:34 ` Ted Baker
2009-07-16 23:07 ` Raistlin
2009-07-15 21:45 ` Ted Baker
2009-07-15 22:12 ` Chris Friesen
2009-07-15 22:52 ` Ted Baker
2009-07-17 13:35 ` Giuseppe Lipari
2009-07-13 17:25 ` Peter Zijlstra
2009-07-13 18:14 ` Noah Watkins
2009-07-13 20:13 ` Ted Baker
2009-07-13 21:45 ` Chris Friesen
2009-07-14 11:16 ` Raistlin
2009-07-15 23:11 ` Ted Baker
2009-07-16 7:58 ` Peter Zijlstra
2009-07-16 8:52 ` Thomas Gleixner
2009-07-16 12:17 ` Raistlin
2009-07-16 12:59 ` James H. Anderson
2009-07-16 13:37 ` Peter Zijlstra
2009-07-16 22:15 ` Ted Baker
2009-07-16 22:34 ` Karthik Singaram Lakshmanan
2009-07-16 23:38 ` Ted Baker
2009-07-17 1:44 ` Karthik Singaram Lakshmanan
2009-07-16 15:17 ` Chris Friesen
2009-07-16 21:26 ` Ted Baker
2009-07-16 22:08 ` Chris Friesen
2009-07-16 23:54 ` Ted Baker
2009-07-14 9:15 ` Peter Zijlstra
2009-07-14 19:07 ` Raistlin
2009-07-13 17:28 ` Peter Zijlstra
2009-07-14 19:47 ` Raistlin
[not found] ` <002301ca0403$47f9d9d0$d7ed8d70$@tlh@comcast.net>
2009-07-13 23:47 ` Douglas Niehaus
2009-07-14 7:27 ` Chris Friesen
2009-07-14 7:44 ` Douglas Niehaus
2009-07-12 6:17 ` Henrik Austad
2009-07-13 9:55 ` Raistlin
2009-07-13 10:14 ` Peter Zijlstra
2009-07-13 16:06 ` Raistlin
2009-07-14 8:42 ` Peter Zijlstra
2009-07-14 9:36 ` Raistlin
-- strict thread matches above, loose matches on Subject: below --
2009-07-16 17:54 Raj Rajkumar
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=1247789977.4929.147.camel@Palantir \
--to=raistlin@linux.it \
--cc=a.p.zijlstra@chello.nl \
--cc=anderson@cs.unc.edu \
--cc=baker@cs.fsu.edu \
--cc=billh@gnuppy.monkey.org \
--cc=cfriesen@nortel.com \
--cc=cucinotta@sssup.it \
--cc=dhaval.giani@gmail.com \
--cc=fabio@gandalf.sssup.it \
--cc=henrik@austad.us \
--cc=jayhawk@soe.ucsc.edu \
--cc=kusp@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=lipari@retis.sssup.it \
--cc=mingo@elte.hu \
--cc=niehaus@ittc.ku.edu \
--cc=tglx@linutronix.de \
/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