[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.
On Thu, Apr 24, 2014 at 08:58:25AM +0100, Jan Beulich wrote: > >>> On 23.04.14 at 23:28, <konrad.wilk@xxxxxxxxxx> 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). <smacks his head> 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 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |