Alan Cox wrote:
>
> > I must not be making my self clear :) The overhead has nothing to do
> > with hardware. It is all timer list insertion and deletion. The
> > problem is that we need to do this at context switch rates, which are
> > MUCH higher that tick rates and, even with the O(1) insertion code,
> > cause the overhead to increase above the ticked overhead.
>
> I remain unconvinced. Firstly the timer changes do not have to
> occur at schedule rate unless your implementaiton is incredibly naiive.
OK, I'll bite, how do you stop a task at the end of its slice if you
don't set up a timer event for that time?
> Secondly for the specfic schedule case done that way, it would be even more
> naiive to use the standard timer api over a single compare to getthe
> timer list versus schedule clock.
I guess it is my day to be naive :) What are you suggesting here?
-- 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 30 2002 - 22:00:10 EST