Re: [RFC PATCH v2 0/7] Repurpose SEDF Scheduler for Real-time Use

From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	Nathan Studer <nate.studer@gmail.com>,
	Josh Whitehead <josh.whitehead@dornerworks.com>
Subject: Re: [RFC PATCH v2 0/7] Repurpose SEDF Scheduler for Real-time Use
Date: Fri, 11 Jul 2014 15:35:49 +0200	[thread overview]
Message-ID: <1405085749.29306.405.camel@Solace> (raw)
In-Reply-To: <1405077340.15107.5.camel@kazak.uk.xensource.com>

[-- Attachment #1.1: Type: text/plain, Size: 2141 bytes --]

On ven, 2014-07-11 at 12:15 +0100, Ian Campbell wrote:
> On Fri, 2014-07-11 at 07:01 +0200, Dario Faggioli wrote:
> > *** Short (well, sort of!) Answer ***
> > Personally, I would prefer to keep SEDF alive at least for a few
> > versions
> 
> As it currently is or somehow partially modified?
> 
As it is we can leave it in place for how long we want, I guess, but
it's useless. My point was that, in a partially modified form, it can
serve as a transition to a nnew scheduler  or even live "forever".

Anyway, I'm ok with deprecation, it that looks the best option.

> > However, the biggest problem of SEDF is its poor support for SMP, and
> > lack of capability for setting scheduling parameters on a per-VCPU
> > basis, which this series (rightfully) does not address.
> > Imagine if, after proper review and cleanups, the set of changes from
> > this series goes in, and no other follow up series makes it by feature
> > freeze, 4.5 will have:
> >  - SCHED_SEDF deprecated, because it was lacking SMP support and support
> >    for per-VCPU scheduling parameters
> >  - SCHED_CBS, _lacking_ SMP support and support for per-VCPU scheduling 
> >    parameters
> > Not ideal. :-/
> 
> If people aren't happy with that situation then I suppose we wouldn't
> accept the series until CBS was more complete.
> 
Exactly my point. Thanks for summarizing. :-D

> And this seems to me to be completely orthogonal to whether the approach
> is to rename or rewrite.
> 
Indeed it is, and that's why I provided a full review to the core part
of this patch series already.

That being said, I felt the need of going a bit farther than that, and
provide some more info on what a series like this should include, in
order to make sense in a non RFC status, or at least my take at this.

That is what this mail was all about. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel