Cc: Andrea Arcangeli <andrea@...>, Andrew Morton <akpm@...>, Christoph Lameter <clameter@...>, Jack Steiner <steiner@...>, Nick Piggin <npiggin@...>, Peter Zijlstra <a.p.zijlstra@...>, <kvm-devel@...>, Kanoj Sarcar <kanojsarcar@...>, Roland Dreier <rdreier@...>, Steve Wise <swise@...>, <linux-kernel@...>, Avi Kivity <avi@...>, <linux-mm@...>, <general@...>, Hugh Dickins <hugh@...>, Rusty Russell <rusty@...>, Anthony Liguori <aliguori@...>, Chris Wright <chrisw@...>, Marcelo Tosatti <marcelo@...>, Eric Dumazet <dada1@...>, Paul E. McKenney <paulmck@...>
You simply will *have* to do it without locally holding all the MM
spinlocks. Because quite frankly, slowing down all the normal VM stuff for
some really esoteric hardware simply isn't acceptable. We just don't do
it.
So what is it that actually triggers one of these events?
The most obvious solution is to just queue the affected pages while
holding the spinlocks (perhaps locking them locally), and then handling
all the stuff that can block after releasing things. That's how we
normally do these things, and it works beautifully, without making
everything slower.
Sometimes we go to extremes, and actually break the locks are restart
(ugh), and it gets ugly, but even that tends to be preferable to using the
wrong locking.
The thing is, spinlocks really kick ass. Yes, they restrict what you can
do within them, but if 99.99% of all work is non-blocking, then the really
odd rare blocking case is the one that needs to accomodate, not the rest.
Linus
--
