RE: FUSYN and RT

["Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>]

>From: Esben Nielsen [mailto:simlo@phys.au.dk]
>
>I think we (at least) got a bit confused here. What (I think) the
thread
>started out with was a clear layering of the mutexes. I.e. the code
obeys
>the grammar
>
> VALID_LOCK_CODE   = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
>                   | VALID_LOCK_CODE VALID_LOCK_CODE
>                   | VALID_RTLOCK_CODE
> VALID_RTLOCK      = LOCK_RTLOCK VALID_RTLOCK_CODE UNLOCK_RTLOCK
>                   | VALID_RTLOCK_CODE VALID_RTLOCK_CODE
>                   | VALID_SPINLOCK_CODE
>                   | (code with no locks at all)
> VALID_SPINLOCK_CODE = ... :-)

Errrr...sorry, /me no comprende but I get the idea :)

Going back to the API problem I guess it'd be possible to code 
an equivalent of __prio_boost [your fusyn_setprio()], 
but it still does not answer another underlying problem. 

mutex_setprio() won't take into account the case where a task
(1) takes a mutex, (2) it is boosted for that, (3) it (or somebody 
else) changes its priority and then (4) it is deboosted. 

[4] will deboost it to the prio (static or RT) it had before 
boosting (at [1]), not the new one set at [3] (am I right, Ingo? I
didn't see any hooks in sched_setscheduler() and friends).

Now, this would be easy to solve: do a hook up in any function that
is going to touch the priority, and then for every owned mutex,
go updating the mutex->owner_prio. 

And now the underlying problem: this is where it gets plenty of 
complex when you have to implement PI transitivity--suddenly whenever
I boost an owner I have to walk all the mutexes that it potentially
owns. This becomes O(fugly) the minute you have an ownership chain
deeper than two or three levels with each owner owning more than a
couple of mutexes.

So that's why I chose to put it in the task struct, it becomes O(1)
at the expense (granted) of having to calc a min each time we compute
the dynamic priority.

But these are implementation details

> ...
>will never hit the RT-level. So assuming the RT-lock based code is
>debugged the error must be in Fusyn based code.

Naaah :)

-- Inaky

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