On Mon, 12 Oct 1998, Glynn Clements wrote:
> Andrea Arcangeli wrote:
>
> > > > So I thougt the defined HZ has to be changed as a 1000 (as you know,
> > > > 100 is a default).
> > >
> > > 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.
Of course you wouldn't.
> > 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's a flip bluffer? Do you mean a flip-flop?
> > > > to implement a exact delay time.
> > >
> > > You can't implement an exact delay time. You'll have to live with
> > > whatever delay you get, or switch to using a real-time OS.
> >
> > Or use udelay() or use the rdtsc to measure how much cycles are passed.
> >
> > 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?)
Perhaps you are both overlooking something. Unless this rdtsc() call
overrides the kernel's scheduler somehow (note: I couldn't find any info on
rdtsc()), then several context switches could (and would) throw off this check.
I think that you can really only achieve a lower bound for your delay.
BTW, when in the hell will 2.2 get here?! I'm losing my patience. I've got a
short fuse as is, and this long wait is killing me.
Andrew
