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.) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
