From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nate Studer Subject: Re: [RFC Patch 0/3] Putting the "Simple" back in sedf. Date: Fri, 14 Mar 2014 16:31:45 -0400 Message-ID: <53236731.4060702@dornerworks.com> References: <1394824400-2796-1-git-send-email-nate.studer@dornerworks.com> <532356F6.4030209@eu.citrix.com> <53236303.5070701@dornerworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53236303.5070701@dornerworks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , xen-devel@lists.xen.org Cc: Ian Campbell , Xi Sisu , Stefano Stabellini , Dario Faggioli , Ian Jackson , Robert VanVossen , josh.whitehead@dornerworks.com List-Id: xen-devel@lists.xenproject.org On 3/14/2014 4:13 PM, Nate Studer wrote: > On 3/14/2014 3:22 PM, George Dunlap wrote: >> On 03/14/2014 07:13 PM, Nathan Studer wrote: >>> From: Nathan Studer >>> >>> 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... Speaking of Dario, I got his e-mail address wrong. My apologies. CC'ing his correct address. > > 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 >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >