Re: [Xen-devel] RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel