From: Nate Studer <nate.studer@dornerworks.com>
To: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>,
Xi Sisu <xisisu@gmail.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Robert VanVossen <robert.vanvossen@dornerworks.com>,
josh.whitehead@dornerworks.com,
Dario Faggioli <dario.faggioli@eu.citrix.com>
Subject: Re: [RFC Patch 0/3] Putting the "Simple" back in sedf.
Date: Fri, 14 Mar 2014 16:13:55 -0400 [thread overview]
Message-ID: <53236303.5070701@dornerworks.com> (raw)
In-Reply-To: <532356F6.4030209@eu.citrix.com>
On 3/14/2014 3:22 PM, George Dunlap wrote:
> On 03/14/2014 07:13 PM, Nathan Studer wrote:
>> From: Nathan Studer <nate.studer@dornerworks.com>
>>
>> With the increased interest in embedded Xen, there is a need for a suitable
>> real-time scheduler. The arinc653 scheduler currently only supports a
>> single core and has limited niche appeal, while the sedf scheduler is
>> widely consider deprecated and is currently a mess.
>>
>> Since both the CBS scheduler proposed by Dario and the schedulers of Xen-RT
>> use an edf scheduler as the lowest-level scheduling mechanism, it seems
>> worthwhile to start repurposing the sedf scheduler instead of creating a
>> completely new scheduler.
>>
>> This patchset begins this repurposing by removing the extra scheduling code
>> that has built up over the years, and returns the sedf scheduler to its
>> simple roots.
>
> Hey Nate,
>
> Thanks for these patches -- what you describe at a high level, making
> sedf a suitable rts for embedded applications, sounds like a great idea.
>
> I think what might be helpful in evaluating whether these patches are a
> good idea at the high level is a bit of a description of where you see
> this going long-term. Can you sketch out, at a high level, what you
> envision the sedf scheduler becoming? What kinds of parameters and
> features *will* it have?
In the long term, a more extensible version of Dario's favorite scheduler, CBS
(Constant Bandwidth Server): a selectable budgeting algorithm that sets vcpu
deadlines with the sedf scheduler on the backend scheduling the vcpu with the
earliest deadline. Preferably it would support other budgeting algorithms as
well such as Total Bandwidth Server, etc...
The parameters for the scheduler would be the budgeting algorithm, server
budget, and the server period. The parameters for the domains/vcpus would be
domain/vcpu budget/timeslice and domain/vcpu period.
Those are our ideas though and I know that Dario and others have ideas as well,
so any feedback is appreciated.
In the short term, we are working on upstreaming a version of the CBS scheduler.
Dario mentored Josh Whitehead, who works with me, in implementing a crude
version of it for his undergraduate project, so we are already half-way there.
http://wiki.xen.org/wiki/Archived/GSoC_2013#Temporal_Isolation_and_Multiprocessor_Support_in_the_SEDF_Scheduler
Nate
>
> -George
>
next prev parent reply other threads:[~2014-03-14 20:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 19:13 [RFC Patch 0/3] Putting the "Simple" back in sedf Nathan Studer
2014-03-14 19:13 ` [RFC Patch 1/3] Remove sedf extra, weight, and latency parameter support Nathan Studer
2014-03-17 8:13 ` Jan Beulich
2014-03-17 17:02 ` Dario Faggioli
2014-03-21 11:16 ` Ian Campbell
2014-03-21 12:25 ` Nate Studer
2014-03-21 16:16 ` Dario Faggioli
2014-03-21 16:50 ` Sisu Xi
2014-03-24 15:44 ` Dario Faggioli
2014-03-14 19:13 ` [RFC Patch 2/3] Remove extra queues, latency scaling, and weight support from sedf Nathan Studer
2014-03-14 19:13 ` [RFC Patch 3/3] Fix formatting and misleading comments/variables in sedf Nathan Studer
2014-03-17 16:49 ` Dario Faggioli
2014-03-17 17:00 ` Nate Studer
2014-03-14 19:22 ` [RFC Patch 0/3] Putting the "Simple" back " George Dunlap
2014-03-14 20:13 ` Nate Studer [this message]
2014-03-14 20:31 ` Nate Studer
2014-03-17 10:29 ` Dario Faggioli
2014-03-17 15:51 ` Dario Faggioli
2014-03-17 17:01 ` Sisu Xi
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=53236303.5070701@dornerworks.com \
--to=nate.studer@dornerworks.com \
--cc=dario.faggioli@eu.citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=josh.whitehead@dornerworks.com \
--cc=robert.vanvossen@dornerworks.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=xisisu@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).