Re: [Xen-devel] RFC: Criteria for checking in core scheduling series

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Mon, 2019-09-09 at 14:44 +0200, Juergen Gross wrote:
> ... using Dario's correct mail address
> 
Thanks! :-)

> On 06.09.19 13:09, George Dunlap wrote:
> > There was a discussion on the community call about the core
> > scheduling
> > series being developed by Juergen Gross [1].  The conclusion can be
> > summarized as follows:
> > 
> > * We normally wait to check in series until they are quite good --
> > all
> > the i's dotted and all the t's crossed
> > 
> > * This is for several reasons; primarily because once code gets
> > checked
> > in, it rarely gets looked at again.  In particular, there's nothing
> > stopping the submitter from neglecting to do important clean-ups,
> > in
> > spite of their best intentions; leaving the maintainer or the rest
> > of
> > the community to do it.
> > 
> > * However, for particularly long, complicated series like the core
> > scheduling series, this can have significant downsides.  Rebasing a
> > 60-patch branch regularly is a lot of churn for little value; and
> > core
> > parts of the series which are mostly complete are currently only
> > getting
> > sporadic dev testing rather than the wide range of testing they
> > would
> > get from being in staging.
> > 
> > * XenServer and SuSE are both long-term community members with a
> > strong
> > incentive to maintain and improve the feature; so the risk of the
> > feature being left for the community to maintian is relatively now.
> > 
"relatively low", I guess. :-)

And, ahem, it's SUSE. :-P :-P :-P

> > With all those things in mind, the conclusion was to lower the
> > "check-in" threshold from what it normally is, in order to allow
> > the
> > series to be checked in in the near future, in enough time at least
> > for
> > the "default off" to be well-tested by the 4.13 release.
> > 
> > The criteria we sketched out were:
> > 
> > * All the patches still need appropriate Ack / R-b's
> > 
> > * There should be reason to believe that the series will have
> > little to
> > no impact on "thread mode" (threads being the unit of scheduling;
> > i.e.,
> > the status quo)
> > 
Performance wise, the benchmarks I was able to run showed that the
overhead of having the series applied, but only using thread mode, was
rather small, at least for most of the workloads.

Of course, the more numbers, the better. And the XenServer's
performance regression benchmarking campaign announced by Andrew will
definitely be very useful.

> > So this would really be a recommendation / license to the various
> > maintainers involved; primarily Dario, I think (since I probably
> > won't
> > have time to review the series).
> > 
Ok. I'm back from vacation and am now looking at the patches. I am
traveling next week, but I hope to be able to continue reviewing during
that.

> > No decisions are official until discussed on xen-devel; so the
> > decision
> > will not be considered official until a few days have passed
> > without
> > objection.  And of course, if anyone at the meeting had a different
> > understanding of what was said, or has something to add, please do
> > so.
> > 
Time is really tight... But I do agree with the points/criteria, and
will do my best to make this happen.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel