From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Fabio Checconi <fchecconi@gmail.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
Gregory Haskins <ghaskins@novell.com>
Subject: Re: [RFC][PATCH 0/8] Use EDF to throttle RT task groups
Date: Wed, 15 Jul 2009 09:50:12 +0200 [thread overview]
Message-ID: <1247644212.7500.202.camel@twins> (raw)
In-Reply-To: <20090709135117.GR14563@gandalf.sssup.it>
On Thu, 2009-07-09 at 15:51 +0200, Fabio Checconi wrote:
> I was thinking about doing things gradually: first extend throttling
> to handle generic periods, then extend the push-pull logic (I think you
> are referring to it with load-balancing) to fully support it, and then
> think about global EDF. I think it would be difficult to do all the
> things at one time.
Agreed.
> About minimal concurrency group scheduling, I am not sure of how we
> would handle CPUs hot insertion/extraction, or how the allocation would
> be done efficiently (avoiding bin-packing issues) online inside the kernel.
Right, since the current interface specifies bandwidth in a single-cpu
normalized fashion, adding/removing cpus will only affect the total
bandwidth available, but should not affect the bandwidth calculations.
So it should not break anything, but it sure might surprise, then again,
hotplug is an explicit action on behalf of the admin, so he pretty much
gets what he asked for :-)
I might have to re-read that mim-concurrency G-EDF paper again, but I
failed to spot the bin-packing issue.
> To adapt the current load-balancer to the choices of the deadline-based
> scheduler I was thinking about using a cpupri-like structure per task_group,
> but now I'm not able to estimate the resulting overhead...
Right, per task_group sounds about the right level for the FIFO
balancer. It gets a little more complicated due to having a dynamic
number of vcpus being served at any one time though.
This will also lead to extra task migrations, but sure, whatever works
first, then make it better.
> Do you think that this gradual approach makes sense?
Yeah it does ;-)
next prev parent reply other threads:[~2009-07-15 7:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-15 18:55 [RFC][PATCH 0/8] Use EDF to throttle RT task groups Fabio Checconi
2009-06-15 18:56 ` [PATCH 1/8] Fix rt_rq->pushable_tasks initialization in init_rt_rq() Fabio Checconi
2009-07-09 10:43 ` Peter Zijlstra
2009-07-10 10:41 ` [tip:sched/urgent] sched: " tip-bot for Fabio Checconi
2009-06-15 19:05 ` [PATCH 2/8] Fix hrtick handling Fabio Checconi
2009-07-09 10:42 ` Peter Zijlstra
2009-06-15 19:06 ` [PATCH 3/8] Replace struct prio_array with an RB tree Fabio Checconi
2009-06-15 19:06 ` [PATCH 4/8] Remove the balancing logic Fabio Checconi
2009-06-15 19:08 ` [PATCH 5/8] Use EDF to throttle RT tasks hierarchically Fabio Checconi
2009-06-15 19:08 ` [PATCH 6/8] Modify the curr/next priority tracking Fabio Checconi
2009-06-15 19:09 ` [PATCH 7/8] Reprogram timers only when necessary Fabio Checconi
2009-06-15 19:09 ` [PATCH 8/8] Use hrtick when available Fabio Checconi
2009-07-09 10:36 ` [RFC][PATCH 0/8] Use EDF to throttle RT task groups Peter Zijlstra
2009-07-09 13:51 ` Fabio Checconi
2009-07-15 7:50 ` Peter Zijlstra [this message]
2009-07-15 12:08 ` Fabio Checconi
2009-07-15 14:25 ` 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=1247644212.7500.202.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=fchecconi@gmail.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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