On 27/06/2017 14:23, Wanpeng Li wrote: >>>> I have considered single_task_running() before. But since there is no >>>> such paravirtual interface currently and i am not sure whether it is a >>>> information leak from host if introducing such interface, so i didn't do >>>> it. Do you mean vcpu_is_preempted can do the same thing? I check the >>>> code and seems it only tells whether the VCPU is scheduled out or not >>>> which cannot satisfy the needs. >>> Can you help to answer my confusion? I have double checked the code, but >>> still not get your point. Do you think it is necessary to introduce an >>> paravirtual interface to expose single_task_running() to guest? > > I think vcpu_is_preempted is a good enough replacement. > For example, vcpu->arch.st.steal.preempted is 0 when the vCPU is sched > in and vmentry, then several tasks are enqueued on the same pCPU and > waiting on cfs red-black tree, the guest should avoid to poll in this > scenario, however, vcpu_is_preempted returns false and guest decides > to poll. ... which is not necessarily _wrong_. It's just a different heuristic. In the end, the guest could run with "idle=poll" even, and there's little the host scheduler can do about it, except treating it as a CPU bound task. 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
