On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso <d...@stgolabs.net> wrote: >> >> It is possible that the paravirt spinlocks could be saved by: >> >> - moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking >> code. > > Ouch, to avoid deadlocks they explicitly need the unlock to occur before > the slowpath tail flag is read.
Well, just make the unlock do the actual real unlock operation ("fastpath"), leaving the TICKET_SLOWPATH_FLAG alone. The unlock path can *test* the flag and do whatever kicking it needs to get people started again, but not clear it again. Then, the clearing could be done by the lockers. That way the unlock path at least doesn't change the spinlock any more - sicne the spinlock might have been free'd at any time after the actual unlock. Or something. I'm handwaving. I really dislike all the paravirt crap we do. It tends to be really ugly, and I'm not just talking about spinlocks. TLB flushing etc tends to get interesting too. > Yeah, you just cannot have a slowpath without reads or writes :D Well, you *could* do the slow-path while holding the lock, and making the actual ock release be the last part of the operation (and do the final unlock with a "cmpxchg" that fails and re-does the slowpath if something changed). Then the slowpath can read and write the lock all it wants. But people generally want to avoid that, since it makes the hold times longer. So the "drop the lock, *then* test if we should do some slow path fixup" tends to be the preferred model, it's just that that model is broken due to the lifetime rules. Making it read-only would at least make it a lot less broken.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/