On Tue, Feb 1, 2011 at 9:44 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Tue, 2011-02-01 at 15:00 -0200, Glauber Costa wrote: >> >> > What you can do is: steal_ticks = steal_time_clock() / TICK_NSEC, or >> > simply keep a steal time delta and every time it overflows >> > cputime_one_jiffy insert a steal-time tick. >> >> What do you think about keeping accounting in msec/usec resolution and >> (thus allowing us to compute half a tick to user/system, other half to >> steal time) only change it to cputime in the last minute? > > its only accounting full tick.. > Yes. The way we ended up dealing with this in irq time case is track it in fine granularity and accumulate over time (internally) but account it (make it visible externally) only in terms of ticks, only when the value being accumulated crosses the tick boundary. This does has a hole when we use 99% of time on tick on irq and use 1% just before the tick on some system, then whole tick will be system and on next tick if there is 1% irq and 99% system then that will be accounted as irq as our accumulated value crosses the tick boundary then. But, such holes on avg should not be worse than not having fine granularity. Thanks, Venki -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
