public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gregory Haskins <gregory.haskins@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	avi@redhat.com, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH 4/4] Convert irq notifiers lists to RCU locking.
Date: Mon, 13 Jul 2009 09:26:21 -0400	[thread overview]
Message-ID: <4A5B35FD.9090208@gmail.com> (raw)
In-Reply-To: <20090713131128.GI28046@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4643 bytes --]

Gleb Natapov wrote:
> On Mon, Jul 13, 2009 at 04:02:56PM +0300, Michael S. Tsirkin wrote:
>   
>> On Sun, Jul 12, 2009 at 03:03:53PM +0300, Gleb Natapov wrote:
>>     
>>> Use RCU locking for mask/ack notifiers lists.
>>>
>>> Signed-off-by: Gleb Natapov <gleb@redhat.com>
>>> ---
>>>  virt/kvm/irq_comm.c |   20 +++++++++++---------
>>>  1 files changed, 11 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
>>> index 5dde1ef..ba3a115 100644
>>> --- a/virt/kvm/irq_comm.c
>>> +++ b/virt/kvm/irq_comm.c
>>> @@ -179,18 +179,18 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
>>>  			break;
>>>  		}
>>>  	}
>>> -	rcu_read_unlock();
>>>  
>>> -	hlist_for_each_entry(kian, n, &kvm->irq_ack_notifier_list, link)
>>> +	hlist_for_each_entry_rcu(kian, n, &kvm->irq_ack_notifier_list, link)
>>>  		if (kian->gsi == gsi)
>>>  			kian->irq_acked(kian);
>>> +	rcu_read_unlock();
>>>  }
>>>  
>>>  void kvm_register_irq_ack_notifier(struct kvm *kvm,
>>>  				   struct kvm_irq_ack_notifier *kian)
>>>  {
>>>  	mutex_lock(&kvm->irq_lock);
>>> -	hlist_add_head(&kian->link, &kvm->irq_ack_notifier_list);
>>> +	hlist_add_head_rcu(&kian->link, &kvm->irq_ack_notifier_list);
>>>  	mutex_unlock(&kvm->irq_lock);
>>>  }
>>>  
>>> @@ -198,8 +198,9 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
>>>  				    struct kvm_irq_ack_notifier *kian)
>>>  {
>>>  	mutex_lock(&kvm->irq_lock);
>>> -	hlist_del_init(&kian->link);
>>> +	hlist_del_init_rcu(&kian->link);
>>>  	mutex_unlock(&kvm->irq_lock);
>>> +	synchronize_rcu();
>>>  }
>>>       
>> This is done under kvm->lock still, which means the lock might be held
>> potentially for a very long time. Can synchronize_rcu be moved out of
>> this lock?
>>
>>     
> Only if kvm_free_assigned_device() will be moved out of this lock.
> Device de-assignment is not very frequent event though. How long do you
> think it may be held? KVM RCU read sections are very brief.
>   

Note that the delay imposed by the barrier is not only related to the
length of the critical section.  The barrier blocks until the next grace
period, and depending on the type of RCU you are using and your config
options, this could be multiple milliseconds.

I am not saying that this is definitely a problem for your design.   I
am just pointing out that the length of the KVM-RCU read section is only
one of several factors that influence the ultimate duration of your
kvm->lock CS.  IIUC, in an ideally designed subsystem, the read-side CS
will be dwarfed by the length of the grace, so the grace (and barriers
against it) are really the critical factor of this type of design.

I am CC'ing Paul in case I am saying something dumb/untrue. ;)

Kind Regards,
-Greg

>   
>>>  int kvm_request_irq_source_id(struct kvm *kvm)
>>> @@ -246,7 +247,7 @@ void kvm_register_irq_mask_notifier(struct kvm *kvm, int irq,
>>>  {
>>>  	mutex_lock(&kvm->irq_lock);
>>>  	kimn->irq = irq;
>>> -	hlist_add_head(&kimn->link, &kvm->mask_notifier_list);
>>> +	hlist_add_head_rcu(&kimn->link, &kvm->mask_notifier_list);
>>>  	mutex_unlock(&kvm->irq_lock);
>>>  }
>>>  
>>> @@ -254,8 +255,9 @@ void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int irq,
>>>  				      struct kvm_irq_mask_notifier *kimn)
>>>  {
>>>  	mutex_lock(&kvm->irq_lock);
>>> -	hlist_del(&kimn->link);
>>> +	hlist_del_rcu(&kimn->link);
>>>  	mutex_unlock(&kvm->irq_lock);
>>> +	synchronize_rcu();
>>>  }
>>>  
>>>  void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, bool mask)
>>> @@ -263,11 +265,11 @@ void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, bool mask)
>>>  	struct kvm_irq_mask_notifier *kimn;
>>>  	struct hlist_node *n;
>>>  
>>> -	WARN_ON(!mutex_is_locked(&kvm->irq_lock));
>>> -
>>> -	hlist_for_each_entry(kimn, n, &kvm->mask_notifier_list, link)
>>> +	rcu_read_lock();
>>> +	hlist_for_each_entry_rcu(kimn, n, &kvm->mask_notifier_list, link)
>>>  		if (kimn->irq == irq)
>>>  			kimn->func(kimn, mask);
>>> +	rcu_read_unlock();
>>>  }
>>>  
>>>  void kvm_free_irq_routing(struct kvm *kvm)
>>> -- 
>>> 1.6.2.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>       
>
> --
> 			Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

  reply	other threads:[~2009-07-13 13:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-12 12:03 [PATCH 0/4] moving irq routing and notifiers to RCU locking Gleb Natapov
2009-07-12 12:03 ` [PATCH 1/4] Move irq routing data structure to rcu locking Gleb Natapov
2009-07-13 12:55   ` Michael S. Tsirkin
2009-07-13 13:03     ` Gleb Natapov
2009-07-13 13:15       ` Michael S. Tsirkin
2009-07-13 13:23         ` Gleb Natapov
2009-07-13 13:36           ` Michael S. Tsirkin
2009-07-13 13:01   ` Gregory Haskins
2009-07-13 13:15     ` Gleb Natapov
2009-07-13 13:16       ` Gregory Haskins
2009-07-13 13:25         ` Gleb Natapov
2009-07-13 13:29           ` Gregory Haskins
2009-07-13 15:55       ` Marcelo Tosatti
2009-07-13 16:24         ` Gleb Natapov
2009-07-13 16:27           ` Marcelo Tosatti
2009-07-13 16:33             ` Gleb Natapov
2009-07-13 16:42               ` Marcelo Tosatti
2009-07-13 16:44                 ` Gleb Natapov
2009-07-13 16:45                   ` Marcelo Tosatti
2009-07-13 16:54                     ` Gleb Natapov
2009-07-12 12:03 ` [PATCH 2/4] Unregister ack notifier callback on PIT freeing Gleb Natapov
2009-07-12 12:03 ` [PATCH 3/4] Move irq ack notifier list to arch independent code Gleb Natapov
2009-07-12 12:03 ` [PATCH 4/4] Convert irq notifiers lists to RCU locking Gleb Natapov
2009-07-13 12:56   ` Michael S. Tsirkin
2009-07-13 13:05     ` Gleb Natapov
2009-07-13 13:29       ` Michael S. Tsirkin
2009-07-13 13:48     ` Gregory Haskins
2009-07-13 13:02   ` Michael S. Tsirkin
2009-07-13 13:11     ` Gleb Natapov
2009-07-13 13:26       ` Gregory Haskins [this message]
2009-07-13 13:32         ` Gleb Natapov
2009-07-13 13:40           ` Gregory Haskins
2009-07-13 13:52             ` Gleb Natapov
2009-07-13 14:02               ` Gregory Haskins
2009-07-13 14:08                 ` Gleb Natapov
2009-07-13 13:40           ` Michael S. Tsirkin
2009-07-13 13:44             ` Gregory Haskins
2009-07-13 19:31             ` Paul E. McKenney
2009-07-14  5:46               ` Gleb Natapov
2009-07-14 12:03                 ` Paul E. McKenney
2009-07-14 12:06                   ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A5B35FD.9090208@gmail.com \
    --to=gregory.haskins@gmail.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox