Anton Blanchard wrote:
>
>
> > Please folks. When can we put the "tick on demand" thing to bed? If in
> > doubt, get the patch from the high-res-timers sourceforge site (see
> > signature for the URL) and try it. Overhead becomes higher with system
> > load passing the ticked system at relatively light loads. Just what we
> > want, very low overhead idle systems!
> >
> > The problem is in accounting (or time slicing if you prefer) where we
> > need to start a timer each time a task is context switched to, and stop
> > it when the task is switched away. The overhead is purely in the set up
> > and tear down. MOST of these never expire.
>
> Did you work out where exactly the overhead was and if it was hardware
> specific? On ppc for example updating the timer is just a write to a cpu
> register.
It has nothing to do with hardware. The over head is putting a timer
entry in the list and then removing it. Almost all timers are canceled
before they expire. Even with the O(1) timer list, this takes time and
when done at the context switch rate the time mounts rapidly. And we
need at least one timer when we switch to a task. In the test code I
only start a "slice" timer. This means that a task that wants a
execution time signal may find the signal delayed by as much as a slice,
but it does keep the overhead lower.
>
> Anton
-- 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/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:36 EST