From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [RFC PATCH v2 0/7] Repurpose SEDF Scheduler for
 Real-time Use
Date: Fri, 11 Jul 2014 16:02:50 -0400
Message-ID: <20140711200250.GN23257@laptop.dumpdata.com>
References: <1404939348-4926-1-git-send-email-josh.whitehead@dornerworks.com>
	<1405003438.26155.12.camel@kazak.uk.xensource.com>
	<1405054902.29306.224.camel@Solace>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <1405054902.29306.224.camel@Solace>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, 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>
List-Id: xen-devel@lists.xenproject.org

> 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. :-/

(With release manager hat on)

Actually I would think it is OK. In terms of X feature count at this
point of time (T) and on 4.5 feature freeze day (T-RC0) if the number of
features is greater or equal we are OK.

What is bad if the amount of features on T-RC0 is less than now (so say
X-1 features). That is not the case.