Re: 2.6.16-rc6-rt1

[Esben Nielsen]

On Sun, 12 Mar 2006, Ingo Molnar wrote:

> i have released the 2.6.16-rc6-rt1 tree, which can be downloaded from
> the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
> again, lots of changes all over the map:
>
> - firstly, the -rt tree has been rebased to 2.6.16-rc6, which was a more
>   complex operation than usual, due to the many changes in 2.6.16 (in
>   particular the mutex code).
>
> - the PI code got reworked again, this time by Thomas Gleixner. The
>   priority boosting chain is now instantaneous again (and not
>   wakeup/scheduling based) - but the previous list-walking hell has been
>   avoided via the clever use of plists. Plus many other changes and
>   lots of cleanups to the rt-mutex proper.

Hi,
 I briefly looked at the PI code. Looks fine. I will try it on my
rt-mutex testbed soonish.

However, I notice it re-introduces long latencies :-(
The problem is that the time need in adjust_prio_chain is proportional to
the lock depth and the function is called with two raw spinlocks held.
This is no problem when the locks are in the kernel and thus not very
deeply nested, but when it is exposed to futexes there is a problem as
Joe user can increase the task latency of the system by crafting deep
locking structures in userspace.

I will be on paternity leave soonish. I might get time solve it as I
originally suggested some months back when my daughter is asleep. The
solution I suggested last fall, includes releasing _all_ locks at each
iteration in the loop in adjust_prio_chain such that higher priority
tasks gets a chance to run. To avoid having tasks released in the middle
get/put_tast_struct() are needed. That will cost extra atomic
instructions compared to the present implementation. Are people prepared
to pay that price? I am not talking about the scheduler based solution;
just doing the PI iteration in a little different (and slightly more
epensive) way.

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/