In article <20021027145728.6e3091ff.chris@dokein.co.uk>
chris@dokein.co.uk wrote:

> Looks fine, my mistake.  Note that you'll still get stat clock overruns
> as the current interrupt handling may not deal with them in a timely
> fashion (do a build of something if it causes enough disk/network io
> then you may find that you get overruns)

You are right, my cats still gets overruns on heavy load.

After I updated my cats' kernel from 1.6I (around Sept.15)
to 1.6H (Oct.14), it got random hangs very often even without load.
(it hanged up on just typing keyboard on single user.)
Then I checked the statclock changes, but maybe it is
different problem..

> it's solving 2 things:
> 1 being you don't always take a statclock interrupt at the same time as
> the hardclock (or near enough)  But you may just end up always taking a
> sample at the same point without the randomness.
> 2 It also helps track where we really are using time otherwise you could
> find that you'll not see a process that's running as it gives up the cpu
> too often.  Adding randomness is normal practice (see
> sparc/sparc/clock.c) and desired.

Ok, I see. I just thought that all timers on footbridge use
the same clock sources and they can reload TIMER_x_LOAD values
automatically in each period, so we could keep intervals
between hardclock and statclock.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp