Hi.
At this time ULE scheduler uses hardclock() ticks via sched_tick() to
estimate threads CPU load. That strictly limits it's best possible
precision and that is one more reason to call hardclock() on every HZ
tick, even when there is no callouts scheduled.
I've made a patch to get CPU load estimation in ULE in event-based way.
It won't immediately increase precision as I still use ticks counter as
time source, but it should be trivial to use more precise one later (if
some global, fast and reliable one is available). What it gives now, is
that sched_tick() function is now empty for ULE, same as it always was
for 4BSD. With some more changes in other areas it should allow to run
hardclock() with full HZ rate only on one non-idle CPU, not on each one
as it is now. One more small step toward tick-less kernel.
Patch can be found here:
http://people.freebsd.org/~mav/sched.notick4.patch
Any comments?
Important theoretical question: what exactly we want to see as CPU load?
ps(1) defines %cpu as: "decaying average over up to a minute of previous
(real) time", but I think that definition is not exactly true now.
As I understand, 4BSD calculates pure decaying average without time
limit -- if not precision limitation, CPU load value would include data
for all the thread life time with exponentially decreasing weight for
old values. ULE behaves partially alike, but has strict idle deadline
after which load considered equal to zero and in some cases it decays
more linearly, that seems also depends on if/how often CPU load is read.
So which way should be considered right? Should it be clear decaying
average as 4BSD does, or should it be something closer to "average load
for last N seconds", following ideas I see in ULE now?
--
Alexander Motin
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
