On Mon, Jul 13, 2009 at 01:23:38PM -0300, Marcelo Tosatti wrote: > On Mon, Jul 13, 2009 at 05:37:50PM +0300, Gleb Natapov wrote: > > On Mon, Jul 13, 2009 at 05:23:20PM +0300, Michael S. Tsirkin wrote: > > > On Mon, Jul 13, 2009 at 02:48:44PM +0300, Gleb Natapov wrote: > > > > On Mon, Jul 13, 2009 at 02:45:51PM +0300, Michael S. Tsirkin wrote: > > > > > On Mon, Jul 13, 2009 at 12:12:33PM +0300, Gleb Natapov wrote: > > > > > > > > > > > > Signed-off-by: Gleb Natapov <[email protected]> > > > > > > > > > > This one is probably better off left as is, > > > > What do you mean "as is"? > > > > > > This is a slow operation. It seems that we could use irq_lock or switch > > > to slot lock or kvm lock here. Why do we need another one? > > > > > irq_lock is completely removed. So either we don't remove it and use it > > here (and we don't need mutex so we change it to spinlock too), or we add > > another lock with the name that actually tell us what its purpose. I prefer > > second option. I am not sure you can use kvm lock without deadlock, and > > slot lock? How this connected to slots management?! > > slots_lock is just a bad name now. See slots_lock is taken for read on > every exit. So taking slots_lock for write means all guests are stopped ^^^^^^
all vcpus > in a known synchronization state. > > If the write side of the operation is very unfrequent (such as > registration of irq ack/mask notifiers), down_write(slots_lock) works as > a simpler replacement for RCU. > > We want to get rid of slots_lock on every exit at some point, though. > > > And this is not about speed of the operation. It is about making reader > > lockless. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
