Hi Stefano,
On 20/02/17 18:47, Stefano Stabellini wrote:
On Sun, 19 Feb 2017, Julien Grall wrote:
I don't think this is acceptable even to get a better interrupt latency.
Some
workload will care about interrupt latency and power.
I think a better approach would be to check whether the scheduler has
another
vCPU to run. If not wait for an interrupt in the trap.
This would save the context switch to the idle vCPU if we are still on the
time slice of the vCPU.
From my limited understanding of how schedulers work, I think this
cannot work reliably. It is the scheduler that needs to tell the
arch-specific code to put a pcpu to sleep, not the other way around. I
would appreciate if Dario could confirm this though.
If my understanding is correct, your workload is 1 vCPU per pCPU. So why do
you need to trap WFI/WFE in this case?
Would not it be easier to let the guest using them directly?
This is a good question, I have already answered: I think it would break
the scheduler. Dario confirmed it in his reply
(1487382463.6732.146.ca...@citrix.com).
I don't think it will break the scheduler, we are trapping WFI/WFE to
take advantage of the quiescence of the guest. If we don't do that, the
guest will just waste his slot.
Even if the WFI is done by the guest, you will receive the scheduler
interrupt in Xen and that's fine. Did I miss anything?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
