Re: [Xen-devel] [PATCH v3 1/4] xen: add real time scheduler rtds

[Meng Xu <xumengpanda@xxxxxxxxx>]

2014-09-22 13:26 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:
> 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'.
>

Agree. I think it's better to be experimental for 4.5 first. Then we
will extend the interface as Dario points out and improve the
performance to make the implementation more efficient.

Meng


-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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