public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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