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

Re: [Xen-devel] [PATCH 1/2] xen: credit2: avoid vCPUs to ever reach lower credits than idle



On Thu, 2020-03-12 at 13:55 +0000, Andrew Cooper wrote:
> On 12/03/2020 13:44, Dario Faggioli wrote:
> > 
> > NOTE: investigations have been done about _how_ it is possible for
> > a
> > vCPU to execute for so long that its credits becomes so low. While
> > still
> > not completely clear, there are evidence that:
> > - it only happens very rarely
> > - it appears to be both machine and workload specific
> > - it does not look to be a Credit2 (e.g., as it happens when
> > running
> >   with Credit1 as well) issue, or a scheduler issue
> 
> On what basis?
> 
On the basis that I have traced execution times of vCPUs, when running
on both Credit1 and Credit2, on a system where I can sort-of reproduce
the issue, and I see them being able to execute for ginormous
timeslices, with both scheduler.

That's what this paragraph above, plus similar ones in the cover letter
,were supposed to mean. If it is not clear enough, sorry.

> Everything reported to xen-devel appears to suggests it is a credit2
> problem.  It doesn't manifest on versions of Xen before credit2
> became
> the default, and switching back to credit1 appears to mitigate the
> problem.
> 
Yes, because even if the issue is there in both cases, when you use
Credit2 it manifests as vCPUs being starved (because of the "they end
up having less priority than the idle vCPU" thing). When you use
Credit1, this does not happen, because time accounting and
prioritization are done differently there.

Switching to Credit1, at least on the box where I could reproduce the
problem, did not make the issue that the vCPUs run for way too long
disappear. It's the symptoms that this issue cause that are different
for the two schedulers.

> Certainly as far as XenServer is concerned, we haven't seen symptoms
> like this in a decade of running credit1.
> 
I am only able to reproduce this issue on one box, and not really 100%
deterministically. I have never noticed anything like this in the past
few years, on Credit2. At least, nothing as severe as this (or we would
have noticed, which is what, in fact, has happened!).

With Credit1, even if the issue is there, you won't notice it in this
form, se we really can't know.

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

 


Rackspace

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