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 [email protected]
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
