[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] remove blocked time accounting from xen "clockchip"

On Fri, Jan 20, 2012 at 09:57:04AM +0000, Jan Beulich wrote:
> >>> On 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> > I finally got some time to look at them and I think they are these ones:
> > 
> > git log --oneline 
> > e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> > 255a4 
> > 3c404b5 KVM guest: Add a pv_ops stub for steal time
> > c9aaa89 KVM: Steal time implementation
> > 9ddabbe KVM: KVM Steal time guest/host interface
> > 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> > interface
> > 
> > What is interesting is that they end up inserting a bunch of:
> > 
> >  
> > +       if (steal_account_process_tick())
> > +               return;
> > +
> > 
> > in irqtime_account_process_tick and in account_process_tick.
> And this (particularly the "return" part of it) is what I have a hard
> time to understand: How can it be correct to not do any of the
> other accounting? After all, the function calls only
> account_steal_time(), but its certainly going to be common that
> part of the time was stolen, and part was spent executing.
> Further, it's being called only from the process tick accounting

Also from 'irqtime_account_idle_ticks' which is called from
account_idle_ticks (if tsc is part of the picture) which is called
from tick_nohz_idle_exit. So at the end of the idle loop the idle
time is accounted for.

> functions, but clearly part of idle or interrupt time can also be
> stolen.

It looks as if the other interrupt times: so the CPUTIME_SOFTIRQ and
CPUTIME_IRQ are completly skipped - but only if there is a "steal time".

The 'steal time' from the KVM is based on the host scheduler notion
of 'run_delay'. I think the 'run_delay' is based purely on block I/O
delay or swap I/O delay. So if the host is not running in any of those
issues, then the 'steal_account_process_tick' won't have any values.
And the 'if (..) return;' wont be taken and it will continue to attribute
the other 'time' slots with appropiate values.

If we have CPU intensive guests that are overcommitted, the guest 
won't show the delay between the host putting it on a CPU as as 'steal' time
but rather as 'idle' time - I think?

That seems odd. I am probably misreading how 'run_delay' gets computed.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.