Hello Julien,
On 23.11.18 15:27, Julien Grall wrote:
But we can't use it, because our system is overcommitted.
Can you describe how overcommitted your system is?
I did mean that we have a requirement to not limit VCPU number with PCPU
number. Also we should not use cpu pinning. I guess I used a wrong word,
it must be "oversubscribed".
I don't understand what you mean. Can you details it?
I hope you do not mind I draw a picture for this. I failed to find a
simple wording for it :(
At some rate of IRQs from different sources, slight reducing of IRQ
processing time in the hypervisor might result in an overly slower IRQs
processing.
So, on the picture attaches, in case2 IRQ processing path in XEN made
shorter. But when we have IRQ1 and IRQ2 asserted at some rate, we result
in two context switches and going through the IRQ processing path twice.
What is longer than catching the IRQ2 right away with IRQ1 in XEN itself.
We come to this idea after observing a strange effect: dropping a bit of
code from IRQ processing path (i.e. several if's) led to the benchmark
shown us a bit smaller numbers.
--
Sincerely,
Andrii Anisov.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
