Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

[john cooper]

Scott Wood wrote:

> On Thu, Oct 21, 2004 at 04:18:12PM -0400, john cooper wrote:
>
> > Yet considering the cost to maintain these lists in priority
> > order with multiple spinlock acquisition sequences due to how
> > the aggregate data structure must be traversed/ordered,
> > I haven't yet convinced myself either way.
>
> Another issue is that if you keep them in order, you have to fix the
> list whenever an owner of a listed mutex changes its priority.
Yes, but my concern was having to backoff in out-of-sequence
spinlock acquisition paths. Looking at it again if the canonical
lock acquisition sequence is a task's mutex-owned list then a
mutex's task-owned list, the nondeterministic backoff (if any)
gets pushed to the case of a waiter blocking on the lock.

> > It isn't obvious to me how this would address the case of a
> > task holding a reader lock on mx-A then blocking on mx-B.
> > Another task attempting to acquire a reader lock on mx-A would
> > block rather than immediately acquiring the lock.
>
> Yes.  However, the contention case should not be optimized at the
> expense of the common case, which can be faster for non-rwlock
> implementations when PI is involved.  On SMP, you'd be introducing a
> bottleneck by taking away rwlocks, but on UP it's only an issue when
> you get preempted or block in a critical section.
My concern is removing what should be available reader
concurrency for the mutex in question. I can't assess
how un/common that may be over all application scenarios.

-john


--
john.cooper@xxxxxxxxxxx

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