Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel