Re: RFC: Ideal Adaptive Spinning Conditions
From: Darren Hart
Date: Mon Apr 05 2010 - 10:07:04 EST
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).
IBM Linux Technology Center
Real-Time Linux Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/