Avi Kivity wrote: > Dong, Eddie wrote: > >>> Yes. FlexPriority will be both faster and safer for those who have it >>> than my hack. >>> >>> It may turn out that patching can improve performance even with >>> FlexPriority: we can patch the APIC EOI write to look if any >>> interrupts are pending, and only exit if the EOI will result in a new >>> interrupt being injected. But it is very possible that this will not >>> be necessary if we can achieve good interrupt mitigation with virtio. >>> >>> >>> >> Mmm, I won't say so. The issues is: A guest EOI (level triggered IRQ) >> need to clear remote IRR bit in IOAPIC side and resample that pin in >> IOAPIC side. >> This one is not easy to do in patched code. >> >> >> > > Hmm... > > The patched code needs to answer the question "what will happen if I EOI > this vector now"? I think kvm can prepare the answer for that question, > since it knows the irq is still asserted and that the mode is > level-triggered. > > Basically the kvm lapic code has to calculate the IRR for a "speculative > EOI" and post that in the shared memory block. If something changes > (the IRQ line is de-asserted, for example) again it has to recalculate it. > > So yes, it will not be easy. > > IMHO high performing devices like virtio have good irq coalescing/mitigation so there is no need to optimize their path. Also even if you we had this improvement there is another time that passes between the time that the irq is acked by the guest and the time that higher layer tasklet is scheduled and really handles the action for that interrupt (duting this time more data should reach the host). Since NAPI/virtio handles these situations also there is no need to have optimizations in the middle. Regards, Dor
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
