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. 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. 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. 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). Paolo -- 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
