On Thu, Dec 20, 2001 at 02:57:55PM -0800, Davide Libenzi wrote:
> On 21 Dec 2001, Momchil Velikov wrote:
> >
> > I'd like to second that, IMHO the RT task scheduling should trade
> > throughput for latency, and if someone wants priority inversion, let
> > him explicitly request it.
>
> No a great performance loss anyway. It's zero performance loss if the CPU
> that has ran the woke up RT task for the last time is not running another
> RT task ( very probable ). If the last CPU of the woke up task is running
> another RT task a CPU discovery loop ( like the current scheduler ) must
> be triggered. Not a great deal anyway.
Some time back, I asked if anyone had any RT benchmarks and got
little response. Performance (latency) degradation for RT tasks
while implementing new schedulers was my concern. Does anyone
have ideas about how we should measure/benchmark this? My
'solution' at the time was to take a scheduler heavy benchmark
like reflex, and simply make all the tasks RT. This wasn't very
'real world', but at least it did allow me to compare scheduler
overhead in the RT paths of various scheduler implementations.
-- Mike - 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 : Sun Dec 23 2001 - 21:00:25 EST