On 23/11/2018 12:58, Andrii Anisov wrote:
Hello Andre,
On 22.11.18 20:04, Andre Przywara wrote:
Is that benchmark chosen to put some interrupt load on the system? Or
is that what the customer actually uses and she is really suffering
from Xen's interrupt handling and emulation?
That it the 3D benchmark used by customer to compare virtualization solutions
from different providers.
If you chose this benchmark because it tends to trigger a lot of
interrupts and you hope to estimate some other interrupt property with
this (for instance interrupt latency or typical LR utilisation), then
you might be disappointed. This seems to go into the direction of an
interrupt storm, where we really don't care about performance, but just
want to make sure we keep running and ideally don't penalise other
guests.
Well, that benchmark itself is rather interrupts oriented (on our HW). It emits
GPU load, so causes very low CPU load, but lot of intrerupts from GPU, video
subsytem, display subsystem. I know about the WFI/WFE problem and `vwfi=native`.
The WFI/WFE problem is mostly because of the context switch. It likely can be
optimized to reduce the overhead.
But we can't use it, because our system is overcommitted.
Can you describe how overcommitted your system is?
Also keep in mind that some instructions here and there in the
interrupt handling path in Xen might not be relevant if you exit the
guest frequently (due to interrupts, for instance). The cost of an exit
will probably dwarf the cost of adding a struct pending_irq to a linked
list or so.
It is clear. As we discussed internally, even making IRQ path shorter, we may
experience the benchmark results drop due to the fact that we are doing more
context switches from guest instead of collecting those interrupts directly from
hyp.
I don't understand what you mean. Can you details it?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
