Re: ULE and current.

On Thu, 11 Dec 2003, Jeff Roberson wrote:

> On Fri, 12 Dec 2003, Bruce Evans wrote:
> > As all top watchers know, %WCPU and especially %CPU take a while to
> > ramp up with SCHED_4BSD.  That's just how the algorithm works.  I don't
> > really understand SCHED_ULE, but think it has more jitter in the
> > percentages because it fakes them based on what it is doing based on
> > much less history than SCHED_4BSD (so they are closer to the transient
> > %[W]CPU than the long-term averages).
>
> In ULE I keep a window of ticks defined by ke_ftick and ke_ltick.  ftick
> is the first tick that we were running and ltick is the last.  This window
> is softly bound to 10 seconds.  There is also the ke_ticks field, which is
> used to record the number of ticks that have occured during this time.
>
> When the window exceeds 10 seconds + 1, the window is reduced to 10
> seconds, and 10% of the ticks are decayed away.  When the value is read,
> it is scaled back to 10 seconds, in case it has grown past 10, but before
> 11.  This also takes care of the situation where ltick is very far in the
> past, and scales the recorded ticks back accordingly.
>
> Do you think 10 seconds is too little history?

Perhaps at very high load averages only.  SCHED_4BSD can keep up to 295
ticks and these take a full 295 seconds to decay if the load average is
147 or thereabouts, and I this much history is actually needed for such
a preposterous load average.

BTW, we should use the process runtimes recorded by mi_switch() (if
we keep doing this) instead of tick counts for scheduling, since they
are much more accurate.  Then clock interrupts might not be needed for
scheduling and the separate statclock interrupt should not be needed
at all.  Statistical timing would still be needed to decompose the
runtime into user+sys times, but that is not needed for scheduling.

Bruce