From: Paolo Bonzini <pbonzini@redhat.com>
To: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
Cc: KVM <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Gleb Natapov <gleb@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Eric Blake <eblake@redhat.com>,
Luonengjun <luonengjun@huawei.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
"Jinxin (F)" <jinxin712@huawei.com>,
Zanghongyong <zanghongyong@huawei.com>
Subject: Re: [RFC] create a single workqueue for each vm to update vm irq routing table
Date: Tue, 26 Nov 2013 13:47:03 +0100 [thread overview]
Message-ID: <52949847.6020908@redhat.com> (raw)
In-Reply-To: <D3E216785288A145B7BC975F83A2ED10448ADCCB@SZXEMA510-MBS.china.huawei.com>
Il 26/11/2013 13:40, Zhanghaoyu (A) ha scritto:
> When guest set irq smp_affinity, VMEXIT occurs, then the vcpu thread will IOCTL return to QEMU from hypervisor, then vcpu thread ask the hypervisor to update the irq routing table,
> in kvm_set_irq_routing, synchronize_rcu is called, current vcpu thread is blocked for so much time to wait RCU grace period, and during this period, this vcpu cannot provide service to VM,
> so those interrupts delivered to this vcpu cannot be handled in time, and the apps running on this vcpu cannot be serviced too.
> It's unacceptable in some real-time scenario, e.g. telecom.
>
> So, I want to create a single workqueue for each VM, to asynchronously performing the RCU synchronization for irq routing table,
> and let the vcpu thread return and VMENTRY to service VM immediately, no more need to blocked to wait RCU grace period.
> And, I have implemented a raw patch, took a test in our telecom environment, above problem disappeared.
I don't think a workqueue is even needed. You just need to use call_rcu
to free "old" after releasing kvm->irq_lock.
What do you think?
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
Cc: "Huangweidong (C)" <weidong.huang@huawei.com>,
KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jinxin (F)" <jinxin712@huawei.com>,
Luonengjun <luonengjun@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Zanghongyong <zanghongyong@huawei.com>
Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table
Date: Tue, 26 Nov 2013 13:47:03 +0100 [thread overview]
Message-ID: <52949847.6020908@redhat.com> (raw)
In-Reply-To: <D3E216785288A145B7BC975F83A2ED10448ADCCB@SZXEMA510-MBS.china.huawei.com>
Il 26/11/2013 13:40, Zhanghaoyu (A) ha scritto:
> When guest set irq smp_affinity, VMEXIT occurs, then the vcpu thread will IOCTL return to QEMU from hypervisor, then vcpu thread ask the hypervisor to update the irq routing table,
> in kvm_set_irq_routing, synchronize_rcu is called, current vcpu thread is blocked for so much time to wait RCU grace period, and during this period, this vcpu cannot provide service to VM,
> so those interrupts delivered to this vcpu cannot be handled in time, and the apps running on this vcpu cannot be serviced too.
> It's unacceptable in some real-time scenario, e.g. telecom.
>
> So, I want to create a single workqueue for each VM, to asynchronously performing the RCU synchronization for irq routing table,
> and let the vcpu thread return and VMENTRY to service VM immediately, no more need to blocked to wait RCU grace period.
> And, I have implemented a raw patch, took a test in our telecom environment, above problem disappeared.
I don't think a workqueue is even needed. You just need to use call_rcu
to free "old" after releasing kvm->irq_lock.
What do you think?
Paolo
next prev parent reply other threads:[~2013-11-26 12:47 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 12:40 [RFC] create a single workqueue for each vm to update vm irq routing table Zhanghaoyu (A)
2013-11-26 12:40 ` [Qemu-devel] " Zhanghaoyu (A)
2013-11-26 12:47 ` Paolo Bonzini [this message]
2013-11-26 12:47 ` Paolo Bonzini
2013-11-26 12:56 ` Gleb Natapov
2013-11-26 12:56 ` [Qemu-devel] " Gleb Natapov
2013-11-26 13:13 ` Paolo Bonzini
2013-11-26 13:13 ` [Qemu-devel] " Paolo Bonzini
2013-11-28 3:46 ` Zhanghaoyu (A)
2013-11-28 3:46 ` [Qemu-devel] " Zhanghaoyu (A)
2013-11-26 16:05 ` Michael S. Tsirkin
2013-11-26 16:05 ` [Qemu-devel] " Michael S. Tsirkin
2013-11-26 16:14 ` Gleb Natapov
2013-11-26 16:14 ` [Qemu-devel] " Gleb Natapov
2013-11-26 16:24 ` Michael S. Tsirkin
2013-11-26 16:24 ` [Qemu-devel] " Michael S. Tsirkin
2013-11-30 2:46 ` Zhanghaoyu (A)
2013-11-30 2:46 ` [Qemu-devel] " Zhanghaoyu (A)
2013-11-26 13:18 ` Avi Kivity
2013-11-26 13:18 ` [Qemu-devel] " Avi Kivity
2013-11-26 13:47 ` Paolo Bonzini
2013-11-26 13:47 ` [Qemu-devel] " Paolo Bonzini
2013-11-26 14:36 ` Avi Kivity
2013-11-26 14:36 ` [Qemu-devel] " Avi Kivity
2013-11-26 14:46 ` Paolo Bonzini
2013-11-26 14:46 ` Paolo Bonzini
2013-11-26 14:54 ` Avi Kivity
2013-11-26 14:54 ` Avi Kivity
2013-11-26 15:03 ` Gleb Natapov
2013-11-26 15:03 ` Gleb Natapov
2013-11-26 15:20 ` Paolo Bonzini
2013-11-26 15:20 ` Paolo Bonzini
2013-11-26 15:25 ` Avi Kivity
2013-11-26 15:25 ` Avi Kivity
2013-11-26 15:28 ` Paolo Bonzini
2013-11-26 15:28 ` Paolo Bonzini
2013-11-26 15:35 ` Avi Kivity
2013-11-26 15:35 ` Avi Kivity
2013-11-26 15:58 ` Paolo Bonzini
2013-11-26 15:58 ` Paolo Bonzini
2013-11-26 16:06 ` Avi Kivity
2013-11-26 16:06 ` Avi Kivity
2013-11-26 16:11 ` Michael S. Tsirkin
2013-11-26 16:11 ` Michael S. Tsirkin
2013-11-26 16:21 ` Avi Kivity
2013-11-26 16:21 ` Avi Kivity
2013-11-26 16:42 ` Paolo Bonzini
2013-11-26 16:42 ` Paolo Bonzini
2013-11-26 16:08 ` Michael S. Tsirkin
2013-11-26 16:08 ` Michael S. Tsirkin
2013-11-26 16:24 ` Gleb Natapov
2013-11-26 16:24 ` Gleb Natapov
2013-11-26 16:27 ` Avi Kivity
2013-11-26 16:27 ` Avi Kivity
2013-11-26 16:38 ` Gleb Natapov
2013-11-26 16:38 ` Gleb Natapov
2013-11-26 16:28 ` Paolo Bonzini
2013-11-26 16:28 ` Paolo Bonzini
2013-11-26 16:29 ` Avi Kivity
2013-11-26 16:29 ` Avi Kivity
2013-11-26 16:37 ` Gleb Natapov
2013-11-26 16:37 ` Gleb Natapov
2013-11-28 6:27 ` Zhanghaoyu (A)
2013-11-28 6:27 ` Zhanghaoyu (A)
2013-11-28 8:55 ` Paolo Bonzini
2013-11-28 8:55 ` Paolo Bonzini
2013-11-28 9:19 ` Gleb Natapov
2013-11-28 9:19 ` Gleb Natapov
2013-11-28 9:29 ` Paolo Bonzini
2013-11-28 9:29 ` Paolo Bonzini
2013-11-28 9:43 ` Gleb Natapov
2013-11-28 9:43 ` Gleb Natapov
2013-11-28 9:49 ` Avi Kivity
2013-11-28 9:49 ` Avi Kivity
2013-11-28 9:53 ` Paolo Bonzini
2013-11-28 9:53 ` Paolo Bonzini
2013-11-28 10:16 ` Avi Kivity
2013-11-28 10:16 ` Avi Kivity
2013-11-28 10:40 ` Paolo Bonzini
2013-11-28 10:40 ` Paolo Bonzini
2013-11-28 10:47 ` Avi Kivity
2013-11-28 10:47 ` Avi Kivity
2013-11-28 11:09 ` Gleb Natapov
2013-11-28 11:09 ` Gleb Natapov
2013-11-28 11:10 ` Paolo Bonzini
2013-11-28 11:10 ` Paolo Bonzini
2013-11-28 11:16 ` Avi Kivity
2013-11-28 11:16 ` Avi Kivity
2013-11-28 11:23 ` Gleb Natapov
2013-11-28 11:23 ` Gleb Natapov
2013-11-28 11:31 ` Paolo Bonzini
2013-11-28 11:31 ` Paolo Bonzini
2013-11-28 11:33 ` Avi Kivity
2013-11-28 11:33 ` Avi Kivity
2013-11-28 10:11 ` Gleb Natapov
2013-11-28 10:11 ` Gleb Natapov
2013-11-28 10:12 ` Avi Kivity
2013-11-28 10:12 ` Avi Kivity
2013-11-28 11:02 ` Gleb Natapov
2013-11-28 11:02 ` Gleb Natapov
2013-11-28 11:18 ` Avi Kivity
2013-11-28 11:18 ` Avi Kivity
2013-11-28 11:22 ` Gleb Natapov
2013-11-28 11:22 ` Gleb Natapov
2013-11-28 11:30 ` Avi Kivity
2013-11-28 11:30 ` [Qemu-devel] " Avi Kivity
2013-11-28 11:33 ` Michael S. Tsirkin
2013-11-28 11:33 ` Michael S. Tsirkin
2013-11-28 11:33 ` Gleb Natapov
2013-11-28 11:33 ` Gleb Natapov
2013-11-26 15:24 ` Avi Kivity
2013-11-26 15:24 ` Avi Kivity
2013-11-28 9:14 ` Zhanghaoyu (A)
2013-11-28 9:14 ` Zhanghaoyu (A)
2013-11-28 9:20 ` Gleb Natapov
2013-11-28 9:20 ` Gleb Natapov
2013-11-26 12:48 ` Gleb Natapov
2013-11-26 12:48 ` [Qemu-devel] " Gleb Natapov
2013-11-26 12:50 ` Gleb Natapov
2013-11-26 12:50 ` [Qemu-devel] " 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=52949847.6020908@redhat.com \
--to=pbonzini@redhat.com \
--cc=eblake@redhat.com \
--cc=gleb@redhat.com \
--cc=haoyu.zhang@huawei.com \
--cc=jinxin712@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=luonengjun@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=weidong.huang@huawei.com \
--cc=zanghongyong@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.