Re: [PATCH 2/2] x86/idle: use dynamic halt poll

[Radim KrÄmÃÅ]

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
>> work well.
> 
> 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
> situations.
> 
> (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
bare-metal.)