>> 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....
Yes, but we'd need some more deterministic way of getting to that state.
Some kind of exponential rolling average of the time required to acquire
the semaphore in contention cases should be cheap to compute, and
relatively responsive to changing conditions.
In the case of a semaphore that becomes available during the spin phase,
the contention time is fairly easy to calculate; in the case that we
gave up and called schedule(), we need to know the time at which the
process actually woke up, rather than the time at which we returned from
schedule(), otherwise we'll overestimate the contention. Is there any
way of obtaining the time that wake_up() moved the current process on to
the run queue?
Jamie's idea of performing some of the work involved in the schedule()
whilst spinning ought to be worked into the design somehow if it's
practical.
Paul
-- Paul Menage Paul.Menage@cl.cam.ac.uk http://www.cl.cam.ac.uk/~pbm1001/ Magdalene College, Cambridge: (01223) 768063 Atlas Room, University of Cambridge Computer Laboratory: (01223) 331859- 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