lkml.org 
[lkml]   [2017]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] x86/idle: use dynamic halt poll
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.)

\
 
 \ /
  Last update: 2017-06-27 16:25    [W:0.081 / U:1.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site