at 12:18 PM, Klaus Jensen <i...@irrelevant.dk> wrote: > On Jul 12 14:26, Klaus Jensen wrote: >> On Jul 9 12:35, Jinhao Fan wrote: >>> Use irqfd to directly notify KVM to inject interrupts. This is done by >>> registering a virtual IRQ(virq) in KVM and associate the virq with an >>> irqfd, so that KVM can directly inject the interrupt when it receives >>> notification from the irqfd. This approach is supposed to improve >>> performance because it bypasses QEMU's MSI interrupt emulation logic. >>> >>> However, I did not see an obvious improvement of the emulation KIOPS: >>> >>> QD 1 4 16 64 >>> QEMU 38 123 210 329 >>> irqfd 40 129 219 328 >>> >>> I found this problem quite hard to diagnose since irqfd's workflow >>> involves both QEMU and the in-kernel KVM. >>> >>> Could you help me figure out the following questions: >>> >>> 1. How much performance improvement can I expect from using irqfd? >> >> This is a level of QEMU/KVM that I am by no means an expert on and I >> would have to let the broader QEMU community comment on this. > > In any case, I'm wary about adding this level of kvm-dependence in the > device. This wont work on non-kvm platforms any more.
Yes, irqfd seems only useful on KVM-based systems. Maybe it is more suitable for vhost or VFIO based solutions which need irqfd to deliver interrupts. > I think you should put irqfd on hold and focus on iothreads :) I’m working on iothread currently. But I also observed a performance regression with iothread enabled. I found ftrace, which is supported by both QEMU and KVM, seems good for analyzing performance issues. I’m currently exploring with ftrace.
