Re: [patch] Real-Time Preemption, plist fixes

[Daniel Walker]

On Sun, 5 Jun 2005, Ingo Molnar wrote:
> 
> but i think the fundamental question remains even on Sunday mornings -
> is the plist overhead worth it? Compared to the simple sorted list we 
> exchange O(nr_RT_tasks_running) for O(nr_RT_levels_used) [which is in 
> the 1-100 range], is that a significant practical improvement? By 
> overhead i dont just mean cycle cost, but also architectural flexibility 
> and maintainability.


	You'll have to explain the "architectural flexibility and 
maintainability" costs . Questioning if plist works correctly isn't 
a long term maintainability problem, in my mind. I don't see any 
architectural costs considering the plist API, which is why I saw a clear 
path to integrate plist in the first place. 

	For me it's strictly a speed question. I was reviewing V0.7.40-04 
and it looks like apples and oranges to me. It's more a question of where 
do you perfer the latency , in up() or in down() .. plist is slower for 
non-RT tasks, but non-RT tasks also get the benefit of priority ordering.

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/