Re: [PATCH 2/2] x86/idle: use dynamic halt poll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux