Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Mar 29, 2018 at 06:25:06AM -0600, Jan Beulich wrote:
> >>> On 29.03.18 at 12:50, <wei.liu2@xxxxxxxxxx> wrote:
> > On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
> >> >>> On 29.03.18 at 12:22, <george.dunlap@xxxxxxxxxx> wrote:
> >> > On 03/29/2018 10:56 AM, Juergen Gross wrote:
> >> >> On 29/03/18 11:53, George Dunlap wrote:
> >> >>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
> >> >>>> Hi all,
> >> >>>>
> >> >>>> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
> >> >>>> features to be included for the release, please make sure they are
> >> >>>> committed by March 30th, 2018.
> >> >>>
> >> >>> March 30th is a public holiday here in the UK.  Is it the same in
> >> >>> Germany?  Would it be OK to say that things sent on Friday can be
> >> >>> committed on Tuesday 3 April if the appropriate maintainer wasn't 
> >> >>> around
> >> >>> to review them?
> >> >>>
> >> >>> If not we should warn people to get their stuff reviewed today if at 
> >> >>> all
> >> >>> possible.
> >> >>>
> >> >>> As it happens I'll be working Friday so I can check in stuff that's got
> >> >>> the right Acks / R-b's; but I won't do last-pass reviews on behalf of
> >> >>> maintainers.
> >> >> 
> >> >> I already thought of shifting the freeze by one week. Main reason is
> >> >> that several maintainers seem to have a backlog of patches to review
> >> >> which IMO should make it into 4.11.
> >> >> 
> >> >> Thoughts?
> >> > 
> >> > Well there's a benefit to this, but also a risk: that people will begin
> >> > to see the "hard freeze" as more like a "soft freeze", that will always
> >> > be pushed back / flexed if you push hard enough.  Part of the purpose of
> >> > setting the hard freeze months in advance is so that people can plan
> >> > ahead and get stuff reviewed in time; part of the reason for having
> >> > 6-month releases is so that the cost of delaying a feature / patchset to
> >> > the next release isn't very high.
> >> 
> >> As mentioned before I think anyway that we should revisit this
> >> hard freeze date approach. I would much favor a hard freeze
> >> date on where it is determined which features are intended to
> >> make it and which not. Right now at least everything related to
> >> Spectre and Meltdown would imo want to go into the category
> >> of "we'll wait until it's in".
> > 
> > You're mixing up two things: features and security fixes (and their
> > subsequent patches). I agree the latter should get special attention
> > because missing those would essentially render a release useless or
> > unattractive.  Meltdown and Spectre fall into the second category, as
> > with all the XSAs.
> 
> Subsequent patches to security fixes, unless they fix bugs in the
> earlier changes, are like feature patches to me. We're not adding
> "new functionality" as George has put it, but only want to recover
> some performance. And the switch to use INVPCID for flushing
> was intended to be done independent of XPTI. So this very much
> is a feature to me, instead of a bug fix.
> 
> Whether recovering performance is to be considered integral part
> of earlier changes causing a loss of performance (especially when
> that loss was expected) is an open question.
> 

It depends. I would say a 30-50% performance loss with XPTI will render
this release useless or unattractive to x86 users, I would argue it is
imperative to gain at least some performance back.  You and Andrew
probably have a good idea when we should call that done for this
release, whether it is just your improvement series or we also need
invpcid.

Wei.

> Jan
> 

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