Re: HZ, preferably as small as possible

[george anzinger <george@mvista.com>]

"Grover, Andrew" wrote:
> 
> > From: CaT [mailto:cat@zip.com.au]
> > On Wed, Jul 10, 2002 at 05:42:51PM -0400, Benjamin LaHaise wrote:
> > > On Wed, Jul 10, 2002 at 02:38:32PM -0700, Andrew Morton wrote:
> > > > OK, I'll grant that.  Why is this useful?
> > >
> > > Think video playback, where you want to queue the frame to
> > be played as
> > > close to the correct 1/60s time as possible.  With HZ=100,
> > the code will
> >
> > Or 1/50 (think PAL), no? (Of course HZ=100 would be sweet for that. ;)
> 
> I don't know if I should mention this, but...
> 
> Win2k's default timer tick is 10ms (i.e. 100HZ) but it will go as low as 1ms
> (1000HZ) if people request timers with that level of granularity. On the
> fly.

This is what the high-res-timers patch does.  It always does
the 1/HZ tick, but if a timer is requested with finer
granularity (resolution) an interrupt is scheduled to take
care of it.  Check it out.  You will find it here:
http://sourceforge.net/projects/high-res-timers/
> 
> So, a changing tick *can* be done. If Linux does the same thing, seems like
> everyone is happy. What are the obstacles to this for Linux? If code is
> based on the assumption of a constant timer tick, I humbly assert that the
> code is broken.
> 
> Regards -- Andy
> -

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml