From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v3 1/4] xen: add real time scheduler rtds Date: Mon, 22 Sep 2014 18:43:27 -0400 Message-ID: <20140922224327.GA2844@laptop.dumpdata.com> References: <1410730649-2417-1-git-send-email-mengxu@cis.upenn.edu> <1410730649-2417-2-git-send-email-mengxu@cis.upenn.edu> <541B038D.4030307@eu.citrix.com> <20140919164422.GA9619@laptop.dumpdata.com> <1411406788.4116.26.camel@Solace.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1411406788.4116.26.camel@Solace.lan> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: ian.campbell@citrix.com, xisisu@gmail.com, stefano.stabellini@eu.citrix.com, George Dunlap , lu@cse.wustl.edu, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, ptxlinh@gmail.com, xumengpanda@gmail.com, Meng Xu , JBeulich@suse.com, chaowang@wustl.edu, lichong659@gmail.com, dgolomb@seas.upenn.edu List-Id: xen-devel@lists.xenproject.org On Mon, Sep 22, 2014 at 07:26:28PM +0200, Dario Faggioli wrote: > On ven, 2014-09-19 at 12:44 -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 18, 2014 at 05:08:45PM +0100, George Dunlap wrote: > > > > deadline, and then address the things I'm bringing up here? Or would it be > > > better to wait until all the issues are sorted and then check it in (even if > > > it's after the deadline)? > > > > We can check it in after the deadline - and have those issues resolved. > > > FWIW, I think the series looks good now, and in fact I sent in my > Reviewed-by for all of it. > > > I am basing this on the assumption that: > > - The risks of regressions to the rest of schedulers is nill (as this is all > > new codepaths (as this is all > > - The risks of regressions to the rest of the code-base is nill (as this is all > > new). > > - The resolution of the 'couple of things' are not going to lead to more > > 'couple of things' and lead to re-design. > > > This is all true, IMO. > > > The common code that is touched does not look scary to me. And both of the > > scheduler maintainers - you and Dariof are OK with the design and the patchset > > (minus the 'couple of things'). > > > Exactly. > > > Are we aim to have this be experimental for Xen 4.5 or do we want this > > to be on the 'stable' ? > > > Not sure. What I'm sure about is that > 1) the interface needs to change a bit, to include support for the > per-vcpu parameters setting (although, that can happen in a > backward compatible way, i.e., not touching or altering neither the > look nor the semantic or the interface we'll be checking in if we > take v4) > 2) there is _a_lot_ to gain, from a performance point of view, and Meng > already agreed on continuing working toward that, after 4.5 > > Having it in is, IMO, important, especially for the new > embedded/mobile/automotive uses of Xen we're seeing in these days (in > fact, I think GlobalLogic is using RT-Xen already, so the upstreaming of > this scheduler would be quite useful at least to them [correct me if I'm > wrong]). > > However, given 2 above, if we mark it as stable, we risk that people > (mostly people not yet involved into Xen development and not on this > mailing list) would try it, run into non-optimal performance, and get > upset/angry. For that reason, I think I'd go for 'experimental for 4.5'. OK, will make sure that it is label as such in the release notes/Wiki. > > Regards, > Dario > > -- > <> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) >