Re: Priority Inheritance Test (Real-Time Preemption)

[Esben Nielsen]

On Mon, 29 Nov 2004, Ingo Molnar wrote:

> 
> * Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > > iteration over a list which can be O(number of waiters * locking
> > > depth) long. As long as we are in the kernel both is "controlled",
> > > i.e. one can see the worst-case number in stress test and know it
> > > can't get worse. *
> > 
> > which list do you mean? Note that the pi_list depends on the number of
> > _RT-tasks_, not on the number of SCHED_NORMAL tasks. So you can create
> > an arbitrary number of SCHED_NORMAL tasks, they wont impact the
> > overhead of mutexes!
> > 
> > i very intentionally made it independent of nr-of-non-RT-tasks.
>
Sorry I overlooked that detail. Also the wait_list on each mutex is
"sorted" (the rt-threads in the beginning and normal threads at the end).
Then there should be no problems. 

However, a full sorting among the rt-tasks along with only holding the
first waiter for each mutex on the pi_waiters list would give it better
performance since the list traversals could be avoided. The worst case
still has a full list traversel at insertion of a waiter, but that would
only happen if the rt-thread sleeps on something not a mutex while holding
one - which is really bad coding style! Otherwise, only increasingly high
priority task can possible get the CPU(s) and get access to locking the
mutex. Thus all insertion will be within the first <number of CPUs>
elements on the list.
 
> and i'm regularly testing this property with 'hackbench 50', which
> creates over a 1000 wildly scheduling non-RT tasks. Latency is not
> affected by such workloads.
>
 
Probably not. Even while doing that you most likely wont build up wait
lists of more than 10, maybe 100 tasks? Doing full traversals with irq
disabled probably wont be meassureable!(?) compared to much other stuff
increasing responsible for the meassured latency.

> 	Ingo

Esben

-
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/