Darren Hart wrote:
> Right, and I'm looking to provide some kernel assistance for userspace
> spinlocks here, and am targeting short lived critical sections as well.
What did you have in mind beyond existing mechanisms
which address sibling contention?
One scenario which AFAICT isn't yet addressed is that
of a userspace spin lock holder taking a scheduling
preemption which may result in other threads piling up
on the lock orders of magnitude beyond normal wait times,
until the lock holder is rescheduled.
-john
--
[email protected]
john cooper wrote:
> Darren Hart wrote:
>> Right, and I'm looking to provide some kernel assistance for userspace
>> spinlocks here, and am targeting short lived critical sections as well.
>
> What did you have in mind beyond existing mechanisms
> which address sibling contention?
>
> One scenario which AFAICT isn't yet addressed is that
> of a userspace spin lock holder taking a scheduling
> preemption which may result in other threads piling up
> on the lock orders of magnitude beyond normal wait times,
> until the lock holder is rescheduled.
That is an excellent example.
Another is the highly fragile performance characteristics of spinlocks
with sched_yield() implementations lead to. As sched_yield
implementations change, the scheduling behavior of the spinning tasks
also changes. As the number of cores grows, more performance tuning is
required. Sched_yield() essentially allows the spinner to spin for a
time and then get off the cpu for a time - but it doesn't have any idea
about the state of the lock owner and it's pure chance if the spinning
task with schedule back in at an opportune time, or if it will just be
adding to the scheduling overhead and CPU resources the owner is still
trying to acquire.
The idea here is to leverage the additional information we have in the
kernel to make more intelligent decisions about how long to spin (as
well as how many tasks should spin).
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team