2017-06-27 15:56+0200, Paolo Bonzini:
On 27/06/2017 15:40, Radim KrÄmÃÅ wrote:
... which is not necessarily _wrong_. It's just a different heuristic.Right, it's just harder to use than host's single_task_running() -- the
VCPU calling vcpu_is_preempted() is never preempted, so we have to look
at other VCPUs that are not halted, but still preempted.
If we see some ratio of preempted VCPUs (> 0?), then we stop polling and
yield to the host. Working under the assumption that there is work for
this PCPU if other VCPUs have stuff to do. The downside is that it
misses information about host's topology, so it would be hard to make it
I would just use vcpu_is_preempted on the current CPU. From guest POV
this option is really a "f*** everyone else" setting just like
idle=poll, only a little more polite.
vcpu_is_preempted() on current cpu cannot return true, AFAIK.
If we've been preempted and we were polling, there are two cases. If an
interrupt was queued while the guest was preempted, the poll will be
treated as successful anyway.
I think the poll should be treated as invalid if the window has expired
while the VCPU was preempted -- the guest can't tell whether the
interrupt arrived still within the poll window (unless we added paravirt
for that), so it shouldn't be wasting time waiting for it.
If it hasn't, let others run---but really
that's not because the guest wants to be polite, it's to avoid that the
scheduler penalizes it excessively.
This sounds like a VM entry just to do an immediate VM exit, so paravirt
seems better here as well ... (the guest telling the host about its
window -- which could also be used to rule it out as a target in the
pause loop random kick.)
So until it's preempted, I think it's okay if the guest doesn't care
about others. You wouldn't use this option anyway in overcommitted
(I'm still not very convinced about the idea).
Me neither. (The same mechanism is applicable to bare-metal, but was
never used there, so I would rather bring the guest behavior closer to