In article <E12PNkc-0003ia-00@saracen.cl.cam.ac.uk> you wrote:
> Wouldn't that lead to rather unstable positive feedback? I suspect that
> you'd find that all semaphores used with spin_adapt() would pretty
> quickly have timeouts set to 0 or infinity.
You may be right. The heuristic I described is a "first guess", but I hope
the idea (vary the "wait-time" based on behavior) is still feasible.
> It may well be somewhat non-deterministic, based on the amount of time
> spent waiting at the first contention for each semaphore, and would be
> very dependent on the value that you choose for the initial timeout
> (i.e. all semaphores that take less than the initial timeout to acquire
> in the first few contended cases would become spin locks, and those
> that take longer than the initial timeout to acquire in the first few
> contended cases would become normal semaphores).
If the original timeout is exactly the time it takes to schedule(), this
might even be the wanted behavior: no overhead for "semaphore" behavior, and
sinlock-like behavior where possible....
> You could possibly get more effective results if you based the timeout
> adaptation on the difference between the times taken on the previous
> and current attempts to acquire the lock - but that would hit the fast
> path quite hard.
The fast path (no contention) should, of course, never have anything to do
with this. I will keep thinking about a better heuristic....
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:19 EST