From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: RUNSTATE_runnable delta time for idle_domain accounted to HVM guest. Date: Thu, 24 Apr 2014 14:02:59 -0400 Message-ID: <20140424180259.GA2412@localhost.localdomain> References: <20140423212824.GB12560@phenom.dumpdata.com> <5358E041020000780000BD41@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WdNzd-0001T3-Qu for xen-devel@lists.xenproject.org; Thu, 24 Apr 2014 18:03:30 +0000 Content-Disposition: inline In-Reply-To: <5358E041020000780000BD41@nat28.tlf.novell.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: Jan Beulich Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xenproject.org, dario.faggioli@citrix.com List-Id: xen-devel@lists.xenproject.org On Thu, Apr 24, 2014 at 08:58:25AM +0100, Jan Beulich wrote: > >>> On 23.04.14 at 23:28, wrote: > > Question 1: Following the code path, schedule_tail > > for the idle domain would call idle_loop. > > > > How do we end up from idle_loop in vcpu_wake? > > > > Is that because the HPET (on another CPU) > > has raised the softirq(TIMER_SOFTIRQ) because the > > timer has expired? > > On another or on the same CPU, because work got moved to the CPU > in question, because some other vCPU in the guest triggered activity > in a vCPU currently on that CPU, or because some guest set timer > expired, needing the vCPU to run again. > > > Question 2: > > > > Who would trigger the SCHEDULE_SOFTIRQ for that? > > I was initially thinking that the 'do_block'. But that > > I think triggers the first call to 'schedule' which > > sets the idle domain to run. Help? It could be > > 'vcpu_kick' but 'v->running=0' (done by schedule->context_saved). > > Help!? Who could it be? > > At the example of the credit scheduler, it's vcpu_wake() -> > csched_vcpu_wake() -> __runq_tickle() that raises the softirq > (if needed). And it is right there in 'vcpu_wake': if ( v->runstate.state >= RUNSTATE_blocked ) vcpu_runstate_change(v, RUNSTATE_runnable, NOW()); --> SCHED_OP(VCPU2OP(v), wake, v); <---- Now I just have to figure out why there is a delta of 6.7msec after the 'vcpu_runstate_change' and the 'wake' triggering the 'schedule' on the CPU that is idle. > > > Then 'schedule' is called where the 'prev' is the idle > > domain and 'next' is the guest. However, because 'next' got > > labelled as 'runstate_RUNNABLE' we account _all of the time > > that the idle domain had been running as belonging to the guest_. > > Not really - together with the state change vcpu_runstate_change() > also sets v->runstate.state_entry_time for the new state, i.e. only > the time since the vCPU became runnable is accounted here. Yup! I somehow missed in the 'vcpu_wake' the 'SCHED_OP' call. Now off to figure out why it takes so long to get the SCHEDULE_SOFTIRQ to get invoked on the CPU. More debugging. Thanks for the pointers! > > Jan >