Dan Hecht wrote:

On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:

quoted

Dan Hecht wrote:

quoted

Sounds good.  I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?

Yes.

quoted

  if so, could you forward the new patch?  does it explicitly prevent
stolen time from getting accounted as  user/system time or does it
just rely on NO_HZ mode sort of happening to work that way (since the
one shot timer is skipped ahead for missed ticks)?

Hm, not sure.  It doesn't care how often it gets called; it just
accumulates results up to that point, but I'm not sure if the time would
get double accounted.  Perhaps it doesn't matter when using
xen_sched_clock().

I think you might be double counting time in some cases. 
sched_clock() isn't really relevant to stolen time accounting (i.e.
cpustat->steal).

I think what you want is to make sure that the sum of the cputime
passed to all of:

account_user_time
account_system_time
account_steal_time

adds up to the total amount of time that has passed.  I think it is
sort of working for you (i.e. doesn't always double count stolen
ticks) since in NO_HZ mode, update_process_time (which calls
account_user_time & account_system_time) happens to be skipped during
periods of stolen time due to the hrtimer_forward()'ing of the one
shot expiry. 

OK, this will need a closer look.

BTW, what are the properties of the vmi read_available_cycles()?  Is
that a per-cpu timer?  If its used as the timebase for sched_clock, how
does recalc_task_prio not get a -ve sleep time?


    J