[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.443 / U:5.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site