Re: [accounting regression since rc1] scheduler updates

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> For sched_clock()'s behavior while the virtual CPU is idle: my current 
> idea for that is the patch below (a loosely analoguous problem exists 
> with nohz/dynticks): it makes sched_clock() valid across idle periods 
> too and uses wall-clock time for that.

Ok, that would mean that sched_clock can just return the virtual cpu
time and the two hooks starts and stops the idle periods as far as the
scheduler is concerned. In this case we can use the patch from Jan with
the new implementation for sched_clock and add the two hooks to the
places where the cpu-idle notifiers are done (do_monitor_call and
default_idle). In fact this could be an idle-notifier. Hmm, I take a
closer look tomorrow when I'm back at the office.

> If a virtual CPU is idle then i think the "real = steal, virtual = 0" 
> way of thinking about idle looks a bit unnatural to me - wouldnt it be 
> better to think in terms of "steal = 0, virtual = real" ? Basically a 
> virtual CPU can idle at "perfect speed", without the host "stealing" any 
> cycles from it. And with that way of thinking, if s390 passed in the 
> real-idle-time value to the new callbacks below it would all fall into 
> place. Hm?

How you think about an idle cpu depends on your viewpoint. The source
for the virtual cpu time on s390 is the cpu timer. This timer is stopped
when a virtual cpu looses the physical cpu, so it seems natural to me to
think that real=steal, virtual=0 because the cpu timer is stopped while
the cpu is idle. The other way of thinking about it is as valid though.

> that way we'd have a meaningful sched_clock() across idle periods too, 
> useful for tracers, better scheduler debug-statistics, etc.

That would be good.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.