2017-06-27 20:07 GMT+08:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>: > > > On 27/06/2017 13:22, Yang Zhang wrote: >>>> >>>> Regarding the good/bad idea part, KVM's polling is made much more >>>> acceptable by single_task_running(). At least you need to integrate it >>>> with paravirtualization. If the VM is scheduled out, you shrink the >>>> polling period. There is already vcpu_is_preempted for this, it is used >>>> by mutexes. >>> >>> 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. Regards, Wanpeng Li -- 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
