All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: Raistlin <raistlin@linux.it>
Cc: Henrik Austad <henrik@austad.us>,
	Peter Zijlstra <peterz@infradead.org>,
	claudio@evidence.eu.com, michael@evidence.eu.com, mingo@elte.hu,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	johan.eker@ericsson.com, p.faure@akatech.ch,
	Fabio Checconi <fabio@gandalf.sssup.it>,
	Dhaval Giani <dhaval.giani@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class
Date: Wed, 30 Sep 2009 11:35:06 -0600	[thread overview]
Message-ID: <4AC396CA.6070302@nortel.com> (raw)
In-Reply-To: <1254326306.11233.147.camel@Palantir>

On 09/30/2009 09:58 AM, Raistlin wrote:
> On Tue, 2009-09-29 at 11:34 -0600, Chris Friesen wrote:

>> a) The child should get an identical bandwidth guarantee as the parent
>> and if that can't be guaranteed then the fork() should fail, maybe with
>> an errno of EBUSY.
>>
> Again, this could be done, pretty easily actually. :-)
> 
>> b) The child should start out with no guarantees (SCHED_OTHER nice 0
>> maybe?) and should have to request a bandwidth guarantee.  This could
>> complicate things in some circumstances because if it can't get the
>> guarantee then it needs to inform the parent somehow.
>>
> Ok, I see and agree, again, to many extents.

> Maybe, since I'm adding (in the next patch I'm going to send
> soon) a flag field in the sched_param_ex structure, we can also use some
> of the bits for deciding how the fork will behave... The main problem
> would be the code will get more complicated, and we thus would have to
> decide if it is worth...

For now it might be best to keep it simple...it can always be extended
later on.  Personally I prefer option "a" above as it makes applications
easier to code.

The only problem that I see is that it will refuse to fork() a task that
has a bandwidth of more than 50% of the system.  I wouldn't expect this
to be a common occurrence, but I could be wrong.

Chris

  reply	other threads:[~2009-09-30 17:37 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22 10:30 [RFC][PATCH] SCHED_EDF scheduling class Raistlin
2009-09-22 11:05 ` Peter Zijlstra
2009-09-22 12:51   ` Raistlin
2009-09-22 18:36     ` Peter Zijlstra
2009-09-23 12:19       ` Raistlin
2009-09-23 12:25         ` Dhaval Giani
2009-09-27  6:55       ` Henrik Austad
2009-09-29 16:10         ` Raistlin
2009-09-29 17:34           ` Chris Friesen
2009-09-30 15:58             ` Raistlin
2009-09-30 17:35               ` Chris Friesen [this message]
2009-09-22 11:58 ` Claudio Scordino
2009-09-22 12:38   ` Peter Zijlstra
2009-09-24 16:08     ` Claudio Scordino
2009-09-22 13:24 ` Daniel Walker
2009-09-22 14:01   ` Raistlin
2009-09-22 14:02     ` Daniel Walker
2009-09-22 16:42     ` Peter Zijlstra
2009-09-22 19:11       ` Ingo Molnar
2009-09-23  0:51         ` checkpatch as a tool (was Re: [RFC][PATCH] SCHED_EDF scheduling class) Daniel Walker
2009-09-23  1:01           ` Joe Perches
2009-09-23  1:11             ` Daniel Walker
2009-09-23 19:24               ` Andy Isaacson
2009-09-24 14:58                 ` Daniel Walker
2009-09-30 12:06               ` Pavel Machek
2009-09-23 12:22             ` Ingo Molnar
2009-09-23 14:43               ` Daniel Walker
2009-09-30 12:04           ` Pavel Machek
2009-09-23  7:03         ` [RFC][PATCH] SCHED_EDF scheduling class Raistlin
2009-09-23 21:39     ` Steven Rostedt
2009-09-24  0:58       ` GeunSik Lim
2009-09-22 16:38   ` Peter Zijlstra
2009-09-22 23:39   ` Jonathan Corbet
2009-09-22 23:55     ` Daniel Walker
2009-09-23  0:06       ` Jonathan Corbet
2009-09-23  0:40         ` Daniel Walker
2009-09-23 11:46           ` Avi Kivity
2009-09-23 12:25             ` Ingo Molnar
2009-09-23 14:50               ` Daniel Walker
2009-09-23 14:58                 ` Avi Kivity
2009-09-23 15:08                   ` Daniel Walker
2009-09-23 15:12                     ` Avi Kivity
2009-09-23 15:24                       ` Daniel Walker
2009-09-30 12:05                 ` Pavel Machek
2009-09-22 20:55 ` Linus Walleij
2009-09-23 13:00   ` Raistlin
2009-09-23 13:22   ` Claudio Scordino
2009-09-23 14:08     ` Linus Walleij
2009-09-23 14:45       ` Raistlin
2009-09-23 12:33 ` Linus Walleij
2009-09-23 12:50   ` Linus Walleij
2009-09-23 13:30   ` Raistlin
2009-09-29 18:15     ` roel kluin
2009-09-30 15:59       ` Raistlin
2009-09-24  0:34 ` GeunSik Lim
2009-09-24  6:08   ` Raistlin
2009-09-24  9:11   ` Claudio Scordino

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=4AC396CA.6070302@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=claudio@evidence.eu.com \
    --cc=dhaval.giani@gmail.com \
    --cc=fabio@gandalf.sssup.it \
    --cc=henrik@austad.us \
    --cc=johan.eker@ericsson.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@evidence.eu.com \
    --cc=mingo@elte.hu \
    --cc=p.faure@akatech.ch \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tommaso.cucinotta@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.