[lkml]   [2005]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, plist fixes

On Sun, 5 Jun 2005, Ingo Molnar wrote:

> * Esben Nielsen <> wrote:
> > [...] In extreme load situations we could end up with a lot of waiters
> > on mmap_sem forinstance.
> what do you mean by extreme load. Extreme number of RT tasks, or extreme
> number of tasks altogether? The sorted-list implementation i had in -RT
> had all non-RT tasks handled in an O(1) way - the O(N) component was for
> adding RT tasks (removal was O(1)).
> so the question is - can we have an extreme (larger than 140) number of
> RT tasks? If yes, why are they all RT - they can have no expectation of
> good latencies with a possible load factor of 140!

I can't really imagine a properly working application having more than 140
RT tasks pounding on the same lock - except maybe if someone tries to run
an RT application on one of those Altrix thingies (#CPUS>140 :-).

But as I said I could imagine a situation where you have some really
important RT tasks you would like to survive even if your low priority RT
tasks does something bad - like keep spawning RT tasks which all waits on
the same lock.

Actually this test would make the difference:



while(!done) {
if(done) break;

If you have enough memory for all the tasks, this kind of code would not
be a problem with plists - it will only take a lot of memory. On the other
hand with sorted lists each thread will take longer time inside raw
spinlocks. At some point it will take the whole 1 sec and basicly nothing
else can run.

Ofcourse you can prevent this with ulimits...

What I would do in this discussion is to abstract the interface:
The rt_mutex code should not care if plists, sorted lists or what ever are
used. It should just have a prio_queue structure and prio_queue_add(),
prio_queue_first(), a prio_queue_for_each macro etc. Then Daniel can play
along with his plists and have it as a config-option for now. Someone who
doesn't care about the memory consumption, could even choose to use the
prio_array from the scheduler!

> Ingo


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-05 16:40    [W:0.057 / U:0.952 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site