[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC]Two ideas to optimize updating irq routing table
From: |
Gonglei (Arei) |
Subject: |
[Qemu-devel] [RFC]Two ideas to optimize updating irq routing table |
Date: |
Tue, 25 Mar 2014 03:19:07 +0000 |
Hi,
Based on discussions in:
http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322
About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but
unfortunately
it looks like SRCU's grace period is no better than RCU. I haven't got any idea
why this, but I suppose the test suggests that SRCU is not very ideal. And this
article(https://lwn.net/Articles/264090/) says that SRCU's grace period is
about
the same to RCU. Although QRCU may have good grace period latency, it's not
merged
in Linux kernel yet.
So I come up with these two ideas.
1) Doing rate limit in kmod's kvm_set_irq_routing, if ioctl rate is OK, we do
call_rcu, else we do synchronize_rcu, and thus avoid from OOM.
Or
2) we start a kthread for each VM, and let the kthread waiting for notification
from ioctl, fetching newest irq routing table, and do the RCU update thing; and
in the ioctl, we simply copy routing table from user space, but without RCU
update,
instead, we notify kernel thread do that. Since the ioctls may be very
frequent,
irq routings that are not set by kthread in time are override with newest irq
tables
from user space. This way, we don't have to set a threshold for ioctl
frequency,
and the ioctl may return sooner than synchronize RCU, letting the ioctl vCPU
have
a better response.
How do you think? Or do you have any better ideas? Thanks in advance.
Best regards,
-Gonglei
- [Qemu-devel] [RFC]Two ideas to optimize updating irq routing table,
Gonglei (Arei) <=