From: "Chris Friesen" <cfriesen@nortel.com>
To: Ted Baker <baker@cs.fsu.edu>
Cc: Raistlin <raistlin@linux.it>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Douglas Niehaus <niehaus@ittc.ku.edu>,
Henrik Austad <henrik@austad.us>,
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: Thu, 16 Jul 2009 08:46:52 -0600 [thread overview]
Message-ID: <4A5F3D5C.1070704@nortel.com> (raw)
In-Reply-To: <20090715221410.GE14993@cs.fsu.edu>
Ted Baker wrote:
> On Tue, Jul 14, 2009 at 12:24:26PM -0600, Chris Friesen wrote:
>
>>> - that A's budget is not diminished.
>> If we're running B with A's priority, presumably it will get some amount
>> of cpu time above and beyond what it would normally have gotten during a
>> particular scheduling interval. Perhaps it would make sense to charge B
>> what it would normally have gotten, and charge the excess amount to A?
> So, it seems most logical and simplest to leave the charges where
> they naturally occur, on B. That is, if you allow priority
> inheritance, you allow tasks to sometimes run at higher priority
> than they originally were allocated, but not to execute more
> than originally budgeted.
I had considered this myself, as the simplicity is appealing.
In this scenario, we're going to disrupt B's scheduling pattern by
forcing it to borrow from its future cpu allocation in order to free up
the lock. It will then be forced to block for a while to make up for
the over-use of it's cpu budget.
I was worried that this "bursty" behaviour could cause problems, but on
reflection it seems like if the application is well-behaved to start
with, maybe we can assume that lock-hold times will be small enough that
this shouldn't cause significant problems.
Chris
next prev parent reply other threads:[~2009-07-16 14:47 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
2009-07-17 7:31 ` Henrik Austad
2009-07-16 14:46 ` Chris Friesen [this message]
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=4A5F3D5C.1070704@nortel.com \
--to=cfriesen@nortel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=anderson@cs.unc.edu \
--cc=baker@cs.fsu.edu \
--cc=billh@gnuppy.monkey.org \
--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=raistlin@linux.it \
--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