In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>I think that is far too much variation.  5 seconds is hard-coded into
>the computation of the load average (constants in cexp[]), so even a
>variation of +-1 ticks breaks the computation slightly.

I have not changed the mean inter-sample time from 5 seconds (*),
so is this really a problem? There will be a slight time-warping
effect in the load calculation, but even for the shorter 5-minute
timescale, this will average out to typically no more than a few
percent (i.e the "5 minutes" will instead normally be approx 4.8
to 5.2 minutes). Apart from a marginally more wobbley xload display,
this should not make any real difference.

If the variation was much smaller than it is in the proposed patch,
you could get a noticable drifting in and out of phase with processes
that have a regular run-pause pattern. Obviously this is a much
bigger problem when the sample period is fixed like it is now, but
I wanted to minimise the possibility of this effect while keeping
the inter-update time "relatively" constant.

The alternative that I considered was to sample the processes once
during every 5-second interval, but to place the sampling point
randomly over the interval. That probably results in a better
synchronisation-avoidance behaviour. However, to incorporate the
sample into the load average requires either waiting until the end
of the interval, or updating the load average at the time of
sampling. The former introduces a new delay into the load average
computation, and the latter results in a lot of very noticable
jitter on the inter-sample interval.

(*) Actually, I have changed the mean by 0.5 ticks, but that is a
bug that I will fix. The "4 + random() % (hz * 2)" should be "4 +
random() % (hz * 2 + 1)" instead.

>Not another SYSINIT (all SYSINITs are evil IMO).  SI_SUB_PSEUDO is
>bogus here -- there are no pseudo ttys here.  sched_setup() is a
>good place to do this initialization.

John Baldwin suggested moving the load average calculation into
kern_synch.c, so it would certainly make sense to initialise it
from sched_setup() then. This seems like a good idea to me; does
that sound OK?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to