Andrea Arcangeli wrote:
> > > > If you change the value of HZ, bad things may happen.
> > >
> > > If bad things will happen you' ll found a bug in the kernel.
> >
> > That depends upon what you change it to, I guess. I wouldn't expect to
> > be able to set HZ to 1E9 and still have a functioning system.
>
> This is true but you can' t generalize that changing HZ must not be done.
I didn't say that it mustn't be done; I said that bad things *may*
happen. Clearly, if you change it by a large enough factor, they will.
I had no idea whether changing it by a factor of 10 (to 1000) on x86
would.
> > > Sure a too high value could stall the machine (bad thing ;-) and a too low
> > > one could decrease too much the scheduling frequency causing some strange
> > > (not bad) things.
> >
> > Would this include flip buffers overflowing? (I thought that was
> > sync'd to HZ).
>
> What is "flip buffers overflowing". Could you point me out the code are
> you referring?
Not to any specific code, but I recall a discussion on the linux-net
list about the serial driver using flip buffers (the IRQ handler
writes to one buffer, read()s are satisfied from the other, the
buffers are flipped on a timer running at HZ. Or at least that's my
recollection; I could be totally wrong). If this is the case, then
making HZ too low could cause the buffer to overrun.
> > > Something like:
> > >
> > > timeout = rdtsc() + 2000cycles;
> > > while (rdtsc() < timout);
> > >
> > > This would delay exactly 2000 cycles. This way you can get the precision
> > > of the frequency of the CPU.
> >
> > Yeah, but the poster wanted to delay for 125ms. Doing this (regularly)
> > using a busy wait sounds like it would starve user-space processes of
> > CPU time (or am I overlooking something?)
>
> No you' re right. I just specifyed it myself. I only want to show to the
> guy all possibilites.
Right. I shouldn't have said `can't'; I should have said `shouldn't'.
Doing a busy wait for 125ms may be fine in a DOS program, but it isn't
the way that one generally writes code for a multitasking kernel.
--
Glynn Clements <[EMAIL PROTECTED]>
