qemu-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]