Re: [Xen-devel] Questions about the use of idle_vcpu[]

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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...

I'll have a go at just disabling the periodic scheduler activation when
cpu is idle in the current code, and if it works, I'll send a patch.

Thanks and 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
http://lists.xen.org/xen-devel