Re: 9.1: boot-time delay? [WORKAROUND FOUND]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I don't fully understand the discussion here.

> Initially people claimed that HZ at 8000 would be a problem,

Well, my experience indicates that it _is_ a problem, at least when
using disks at piixide (or pciide).

> which for me seems a bit backwards.

Me too.  I was - am - rather puzzled by it.

> I can only see two real problems with a high clock frequency:

> 1. The overhead of just dealing with clock interrupts increase.

Yes.  This is a potential issue.  When I set HZ=8000 it was one of the
first things I looked at.  The extra interrupt handling load is
measurable, but small enough that it was an acceptable price for making
the application work.  IIRC it was on the order of 1-2% of one core.

> 2. If there are things that just give time in ticks, then ticks
> become very short.  And if the assumption is that just one tick is
> enough, such an assumption can fail.

Yes.  But I have trouble seeing how such a failure could lead to a
delay that is (approximately) linear in HZ.  The only thing I've been
able to think of is that some delay somehow is having mstohz(), or
moral equivalent, applied to it twice.  That is, mstohz is applied, and
then some other code assumes the result is ms rather than ticks and
applies mstohz to it again.  At HZ=100 this means you get a tenth the
delay you think you're getting.  At HZ=1000 it's what it should be.  At
HZ=8000 it's eight times what it should be.  Based on that theory, I
would suspect someone has written a delay number that should be three
seconds and is actually getting .3 seconds at HZ=100, going up to 6s at
HZ=2000, 12s at 4000, and 24s at 8000, but about 2s of other stuff
happens in parallel with it, so I see the delay as 2s shorter than it
is.  I could easily see myself thinking "weird, I have to ask for
3000ms to get a delay long enough for this to work, doesn't _look_ like
three seconds, must investigate sometime" and never getting around to
actually investigating.

My principal reason for thinking this is so is that when I disabled
USB, the delay (at HZ=8000) went from 22s to about 24s - but the
absolute time at which the delay ended, the number printed in brakcets,
stayed (approximately) constant at about 25.3.  This matches well with
the theory that a delay of about 24s starts early and runs in parallel
with the rest of autoconf, and USB takes about two seconds, so I see
22s of delay.  But then when I disable USB, it doesn't hide 2s of that
24s, so I see the whole thing.  (I'd suspect 25s of delay except that
the numbers in brackets seem to start at 1.  Also, 24s matches better
with something getting multiplied by 80 than 25 does.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B