Re: [PATCH 3/5] Move irq notifiers lists to its own locking.

[Marcelo Tosatti <mtosatti@redhat.com>]

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 <gleb@redhat.com>
> > > > > 
> > > > > 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.