Re: Incorrect CPU process accounting using CONFIG_HZ=100

[Peter Williams <pwil3058@bigpond.net.au>]

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@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce