Re: Incorrect CPU process accounting using CONFIG_HZ=100

[Peter Williams]

Al Boldi wrote:
> Peter Williams wrote:
> > Con Kolivas wrote:
> > > On Tuesday 27 June 2006 22:32, Al Boldi wrote:
> > > > Pavel Machek wrote:
> > > > > On Thu 2006-06-22 20:36:39, Al Boldi wrote:
> > > > > > Jan Engelhardt wrote:
> > > > > > > > Setting CONFIG_HZ=100 results in incorrect CPU process accounting.
> > > > > > > >
> > > > > > > > This can be seen running top d.1, that shows top, itself, consuming
> > > > > > > > 0ms CPUtime.
> > > > > > > >
> > > > > > > > Will this bug have consequences for sched.c?
> > > > > > > Works for me, somewhat.
> > > > > > > TIME+ says 0:00.02 after 70 secs. (Ergo: top is not expensive on
> > > > > > > this CPU.)
> > > > > > That's what I thought for a long time.  But at closer inspection, top
> > > > > > d.1 slows down other apps by about the same amount of time at 1000Hz
> > > > > > and 100Hz, only at 1000Hz it is accounted for whereas at 100Hz it is
> > > > > > not.
> > > > > It is not a bug... it is design decision. If you eat "too little" cpu
> > > > > time, you'll be accouted 0 msec. That's what happens at 100Hz...
> > > > Bummer!
> > > The actual problem is that tasks
> > > only get charged if they happen to be running at the precise moment the
> > > tick fires. Now you could increase the accuracy of this timekeeping but
> > > it is expensive and this is exactly the sort of thing that we're saving
> > > cpu resources on by running at 100HZ (one of many).
> > It could be (partly) done fairly cheaply in nanoseconds if sched_clock()
> > was reliable enough (but comments on this mail list indicate that it
> > currently isn't) as it is already called in all the right places for
> > getting the total cpu time used (so just a subtraction, addition and
> > assignment).  The reason that I say partly is that splitting the time
> > into "system" and "user" would be a more complex problem.
>
> If I am reading this correctly, then the kernel is accounting process times 
> twice:
> 	1. for external proc monitoring, using a probed approach
> 	2. for scheduling, using an inlined approach

Not exactly (e.g. there's no separation between user and sys time 
available in line) but the possibilities are there.

> Wouldn't merging the two approaches be in the interest of conserving cpu 
> resources, while at the same time reflecting an accurate view of cpu 
> utilization?

I think that this would be a worthwhile endeavour once/if sched_clock() 
is fixed.  This is especially the case as CPUs get faster as many tasks 
may run to completion in less than a tick.

Peter
--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/