[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] Event channel vs current scheme speed [was vIOSAPIC and IRQs delivery]
I'd like to narrow the discussion on this problem within this thread. We all agree we'd like to support shared IRQs and drivers domain. I am saying I can do that without event channel, while Eddie says it is required. One of Eddie argument is performance, as discussed previously. Since I don't agree and things should be obvious here, I'd like to understand why we don't agree. See my comments. > >> 4: More new hypercall is introduced and more call to hypervisor. > > Only physdev_op hypercall is added, but it is also used in x86 to set > > up IOAPIC. You can't avoid it. > > Initial time is OK for no matter what approach, runtime is critical. Ok. > I saw a lot of hypercall for RTE write. Did you see them by reading the code or by running ? There are hypercalls to mask/unmask interrupts. Is it a performance bottleneck ? I don't think so, since masking/unmasking shouldn't be very frequent. Please tell me if I am wrong. There are also hypercalls to do EOI. This can be a performance issue. If the interrupt is edge triggered, EOI is not required and could be optimized out if not yet done. If the interrupt is level-triggered, then it is required and I don't understand how event-channel can avoid it. For me, this is the purpose of hypercall PHYSDEVOP_IRQ_UNMASK_NOTIFY. Xen has to know when all domains have finished to handle the interrupt. Finally, there is the LSAPIC TPR, IVR and EOI. I think the overhead is very small thanks to Dan's work. And this overhead was measured with the timer. In my current understanding, I don't see the performance gain of event-channel. And I repeat, I'd like to understand. Tristan. _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |