Re: Priority Inheritance Test (Real-Time Preemption)

[Esben Nielsen]

On Mon, 22 Nov 2004, john cooper wrote:

> Ingo Molnar wrote:
> > [...]
> 
> Yes I see where you are walking the dependency chain
> in pi_setprio().  But this is under the global spinlock
> 'pi_lock'.
> 
> My earlier comment was of the difficulty to establish fine
> grained locking, ie: per-mutex to synchronize mutex
> ownership/waiter lists and per task to synchronize
> the list maintaining mutexes owned by task.  While this
> arguably scales better in an SMP environment, there are
> issues of mutex traversal sequence during PI which lead
> to deadlock scenarios.  Though I believe there are
> reasonable constraints placed on application mutex
> acquisition order which side step this problem.
>

In the implementation I sent out earlier (I called it -U9.2-priom) I
solved this by releasing all locks before going to the next task in the
dependency chain. This leaves me open to rescheduling in the middle and
some of the tasks could exit before I got to them. To solve this I used
task_get/put() to make sure the task struct doesn't disappeare before the
next lock is taken. All this locking/unlocking, task_get/task_put is
ofcourse an overhead, but besides avoiding one big lock it gives one more
advantage: It decreases the amount of time a spin lock is held, thus
descreasing the penalty to the overall latency.

 
> In the current design pi_lock has scope protecting all
> mutex waiter lists (rooted either in mutex or owning task),
> as well as per-mutex owner(s).  The result of this is
> pi_lock must be speculatively acquired before altering
> any of the above lists/data regardless whether a PI
> scenario is encountered.  The behavior looks correct to
> my reading.  However I'd offer there is more concurrency
> possible in this design.
> 
I think that is a good approach on UP: Disable preemption, do the sorting
etc., enable preempion. On SMP, however, a global lock is not so nice...

However, I am thinking: Fix the bugs in the current implementation, then
try to optimize it.


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