Messages in this thread | | | Date | Fri, 13 Jan 2012 16:30:50 +0000 | From | "Jan Beulich" <> | Subject | ticket spin locks vs. interrupt re-enabling during spin loops |
| |
Hi Nick,
prior to your introduction of ticket locks on x86 interrupts would get re-enabled in what was then called __raw_spin_lock_flags(). While I realize that this is tricky with ticket locks, have you ever thought through what it would take to implement this correctly?
We had this working well in our Xen kernels up to 2.6.39, but the changes to try_to_wake_up() in 3.0 uncovered a problem with the original implementation, and so I'm now struggling with finding a solution that can cover both this problem as well as to another possible scenario I meanwhile thought of that would break with the original code (an open coded spinning loop over spin_trylock() continuing until success in a scenario similar to that in the new try_to_wake_up()). A draft implementation that I had put together today isn't working quite right yet (and hence I can't quantify its performance impact at all).
One fundamental question of course is whether this really is worth it at all, since re-enabling interrupts here inherently implies that tickets may need to be dropped, and hence the fairness they are intended to guarantee is being undermined. But keeping interrupts frequently disabled for virtually indefinite periods of time (as can happen in a CPU over-committed virtualized environment) is certainly a problem that's worth considering solutions for.
Jan
| |