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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
