Re: [Xen-devel] [PATCH 1/4] xen: credit2: implement utilization cap

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2017-06-28 at 20:05 +0100, George Dunlap wrote:
> On Wed, Jun 28, 2017 at 3:56 PM, Dario Faggioli
> <dario.faggioli@xxxxxxxxxx> wrote:
> > 
> > In the case you describe, at 2T, with budget -C, the first round of
> > the
> > loop will make the budget 0, and set the next replenishment to 3T.
> > As
> > you say, since budget is 0, and 0 is <= than 0, we stay in the loop
> > for
> > another round, which sets the budget to C, and the next
> > replenishment
> > to 4T.
> 
> Ah, right -- I did notice that next_repl was being moved forward each
> iteration too, but didn't connect that it would mean you'd end up
> going for 2T without calling repl_sdom_budget() again.
> 
> So I'm convinced that this behavior won't break the credit system,
> but
> I'm not sure why it's an advantage over just having the domain "sit
> out" this time period.
> 
I think they're just two different possible implementations, and it's
hard to tell, in general, which one is better and which one is worse

Depending on very specific characteristics of the workload, in
combination with what actually caused the specific occurrence of such a
big overrun, and maybe even other factors, either one may behave better
or worse.

E.g., if the vcpu is "greedy", and always tries to run, as soon as it
has some budget, the difference between the two solution is _where_ we
put the "sitting period".

> Did you actually see this happen in practice on a regular basis
> during
> your tests, or is this mostly a hypothetical situation we're talking
> about here?
> 
It's a safety catch. It really should not happen except from bugs or
unless something is really wrong (e.g., in HW). It may happen more
regularly if the user manages to set a budget that is really small,
compared to the actual resolution of the budget enforcing logic (which
is whatever time granularity we use for timers, in that specific host).

There are measures already in place to try to prevent that to happen,
but I probably can add some more... including a WARN() in this very
case.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

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