Re: No 100 HZ timer !

george anzinger
2001-08-02T06:04:14Z

Rik van Riel wrote:
>
> On Wed, 1 Aug 2001, george anzinger wrote:
> > Chris Friesen wrote:
> > > george anzinger wrote:
> > >
> > > > The testing I have done seems to indicate a lower overhead on a lightly
> > > > loaded system, about the same overhead with some load, and much more
> > > > overhead with a heavy load. To me this seems like the wrong thing to
> > >
> > > What about something that tries to get the best of both worlds? How about a
> > > tickless system that has a max frequency for how often it will schedule? This
> >
> > How would you do this? Larger time slices? But _most_ context
> > switches are not related to end of slice. Refuse to switch?
> > This just idles the cpu.
>
> Never set the next hit of the timer to (now + MIN_INTERVAL).
>
> This way we'll get to run the current task until the timer
> hits or until the current task voluntarily gives up the CPU.

The overhead under load is _not_ the timer interrupt, it is the context
switch that needs to set up a "slice" timer, most of which never
expire. During a kernel compile on an 800MHZ PIII I am seeing ~300
context switches per second (i.e. about every 3 ms.) Clearly the
switching is being caused by task blocking. With the ticked system the
"slice" timer overhead is constant.
>
> We can check for already-expired timers in schedule().

Delaying "alarm" timers is bad form.
Especially for someone who is working on high-res-timers :)

George