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

[George Dunlap <george.dunlap@citrix.com>]

On 06/29/2017 11:09 AM, Dario Faggioli wrote:
> 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@citrix.com> 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".

Sorry, dropped this thread to prepare for XenSummit.

Well I think there's a principle a bit like Ockham's Razor: In general,
if there's not an obvious advantage between two implementations, the
simpler / easier to understand implementation is better.

My sense is also that in general, as long as context switching overhead
doesn't become an issue, allowing a guest to run for shorter bursts more
often is better than allowing it to run for longer bursts less often.  A
cpu-bound task will perform about as well in both cases, but a
latency-sensitive task will perform much worse if it's allowed to burn
up its timeslice and forced to wait for a big chunk of time.

On the other hand, my intuitions about how to improve AFL fuzzing these
last few weeks have turned out to be consistently wrong, so at the
moment I'm not inclined to be overly confident in my intuition without
some testing. :-)

I guess in summary: my *advice* would continue to be to not loop until
there's credit, but to allow it to "sit out" a budget period sooner
rather than later.  But if you continue to be convinced that the loop is
better, I'll give my Ack.

 -George

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