[Xen-devel] Load calculation refresh in credit2 (was in Re: Questions about the use of idle_vcpu[])

[George Dunlap <george.dunlap@xxxxxxxxxx>]

[Changing the title to align with the current topic]

On 18/01/16 12:47, Dario Faggioli wrote:
> On Mon, 2016-01-18 at 12:37 +0000, George Dunlap wrote:
>> On Mon, Jan 18, 2016 at 11:00 AM, Dario Faggioli
>> <dario.faggioli@xxxxxxxxxx> wrote:
>>>>  
>>> Credit2, AFAICR, could also avoid _always_ re-setting the timer,
>>> but it
>>> does need to do that at least a few times, even when idle is
>>> selected,
>>> because of the dynamic load tracking mechanism it includes. In
>>> fact,
>>> that is based on a 'decaying average', which in turns relies on
>>> csched2_schedule() to run and update the statistics, even when the
>>> cpu
>>> is idle. If we don't do that, the load tracking mechanism will
>>> never
>>> see that the cpu (well, it's actually the runqueue) is idle, and
>>> the
>>> load will never go down! :-/
>>
>> I don't think that's true -- it looks like balance_load() will call
>> __update_runq_load() on the "other" runqueue before considering it,
>> and will also call __update_svc_load() on each vcpu before
>> considering
>> it.  Shouldn't that suffice?
>>
> Mm... It looks like it should.
> 
> And yet, I observed that 'load not going down' behavior while doing
> development for the patch I mentioned, both on Credit2 and Credit (with
> patches for extending the load tracking to Credit applied).
> 
> I was, in the same series, also trying to optimize the Credit2's load
> balancer a little bit, though, so what I saw may be the effect of some
> other change of mine...

Hmm... Did you see it when the system was under load, or mostly idle?

Load balancing only happens on a reset event; and the frequency of reset
events will be CREDIT_INIT / (% utilization); so for a system at 1%
utilization that would be once every second.  Is that the kind of number
you were seeing?  Or were you actually seeing idle runqueues not having
anything pushed to them *during* a balance for some reason?

 -George

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