On Tuesday 27 June 2006 22:32, Al Boldi wrote:Pavel Machek wrote:On Thu 2006-06-22 20:36:39, Al Boldi wrote:Bummer!Jan Engelhardt wrote:It is not a bug... it is design decision. If you eat "too little" cpuThat's what I thought for a long time. But at closer inspection, topSetting CONFIG_HZ=100 results in incorrect CPU process accounting.Works for me, somewhat.
This can be seen running top d.1, that shows top, itself, consuming
0ms CPUtime.
Will this bug have consequences for sched.c?
TIME+ says 0:00.02 after 70 secs. (Ergo: top is not expensive on this
CPU.)
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.
time, you'll be accouted 0 msec. That's what happens at 100Hz...
Meanwhile, can't "too little" cpu time be made relative to CONFIG_HZ?
It is and that's what you're perceiving as the problem. We only charge tasks in ticks and it's the tick size they get charged with. So at 100HZ if a task is running when a tick fires it gets charged 1% cpu. If it runs for 100 ticks it gets charged with 100% cpu. At 1000HZ it gets charged .1% cpu per tick and so on. 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).