ticket spin locks vs. interrupt re-enabling during spin loops

[Jan Beulich]

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

--
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/