From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Load calculation refresh in credit2 (was in Re: Questions about the use of idle_vcpu[]) Date: Mon, 18 Jan 2016 14:12:08 +0000 Message-ID: <569CF2B8.9020406@citrix.com> References: <569845B7.2060207@seas.upenn.edu> <1453114800.11427.78.camel@citrix.com> <1453121249.11427.83.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1453121249.11427.83.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , George Dunlap Cc: Tianyang Chen , Meng Xu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org [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 >> 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