Re: RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Apr 24, 2014 at 08:58:25AM +0100, Jan Beulich wrote:
> >>> On 23.04.14 at 23:28, <konrad.wilk@oracle.com> 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
>