Messages in this thread | | | Date | Thu, 11 Jul 2002 00:09:49 -0700 | From | george anzinger <> | Subject | Re: HZ, preferably as small as possible |
| |
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |