Messages in this thread | | | Date | Fri, 08 Feb 2002 09:34:58 +0100 | From | Martin Wirth <> | Subject | Re: [RFC] New locking primitive for 2.5 |
| |
Robert Love wrote:
> Some of the talk I've heard has been toward an adaptive lock. These > are locks like Solaris's that can spin or sleep, usually depending on > the state of the lock's holder. Another alternative, which I prefer > since it is much less overhead, is a lock that spins-then-sleeps > unconditionally.
Dave Hanson wrote:
> he spin-then-sleep lock could be interesting as a replacement for the > BKL in places where a semaphore causes performance degredation. In > quite a few places where we replaced the BKL with a more finely grained > semapore (not a spinlock because we needed to sleep during the hold), > instead of spinning for a bit, it would schedule instead. This was bad > :). Spin-then-sleep would be great behaviour in this situation.
Wouldn't it be sufficient to include the following patch of code at the beginning of __combi_wait(...):
if (smp_processor_id() != owner->cpu) { int cnt=MAX_LOOP_CNT; retry: spin_unlock(&x->wait.lock) do { barrier(); while (--cnt && x->owner); spin_lock(&x->wait.lock); if (!x->owner) return; if (cnt) goto retry; } then the sleep code of __combi_wait(...)
If one fears that the owner (or current if the kernel is made preemptible) migrated to the same cpu while we are spinning for x->owner and hence may make no progress, one could let the waiting loop last about a typical process switch time and add an outer loop that checks if the cpu of the owner is still different.
Martin Wirth - 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/
| |