[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Backports to 4.13



On 06.03.2020 15:31, Andrew Cooper wrote:
> On 06/03/2020 14:11, Jan Beulich wrote:
>> On 06.03.2020 14:52, Andrew Cooper wrote:
>>> Depending on the view of other PV shim usability issues, 6dd95b02ea27
>>> and f9dee1f945eb regarding vtsc make a large difference and should be
>>> considered.
>> I've queued the latter, but the former doesn't really look like
>> backporting material to me.
> 
> It is a functional prerequisite.  The stats in the former are protected
> by the lock which is removed by the latter.

Not really, no - the same stats also get update without that lock
in _hvm_rdtsc_intercept(). Plus in your patch description you
also state this: "(currently they left unprotected for HVM domains)".
It's debugging only code really, which I don't think does much harm
when left in.

> An alternative (in theory) would be to change the stats to atomic64_t's,
> except that we don't have any of that infrastructure.  Given that we
> already considered deleting those stats several years ago (due to being
> of dubious use to begin with), I told Igor not to waste time trying to
> fix it differently.

I can certainly see this as one valid way to approach this.

>>> 188f479de4b7 and 005de45c887e are both core scheduling bugfixes and
>>> should be considered, even if they are a little too fresh right at the
>>> moment.
>> "Freshness" is not an issue imo. They've passed the push gate on
>> master, and I wouldn't get around to apply them right away anyway.
>> With these it's just the typical situation for features that are
>> still "experimental" or alike - I'm never really certain whether
>> it's better to pull in such fixes (and have more code churn) or
>> to leave them out. And explicit request like this one of yours
>> helps take a decision.
> 
> In this case, they are concrete bugfixes which were discovered, and
> confirmed fixed, by XenServers testing on a 4.13 base.
> 
> My main purpose in highlighting them is simply that they don't get
> missed for 4.13.1.  After all, there are still other blocking bugs with
> core scheduling even on staging.

To be honest, them getting missed wouldn't be a problem as long as
we don't mean to move core scheduling out of its experimental state
for 4.13.1. Backporting such fixes really is optional, and I'd
likely stop doing so if the volume increased meaningfully.

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.