Re: disabling halt polling broken? (was Re: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a ne

Christian Borntraeger <[email protected]>
Newsgroups org.kernel.vger.kvm-ppc,dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mips
Message-ID <[email protected]>

Am 27.09.21 um 18:58 schrieb David Matlack:
> On Mon, Sep 27, 2021 at 8:17 AM Christian Borntraeger
> <[email protected]> wrote:
>>
>>
>>
>> Am 27.09.21 um 17:03 schrieb Paolo Bonzini:
>>> On 27/09/21 16:59, Sean Christopherson wrote:
>>>>> commit acd05785e48c01edb2c4f4d014d28478b5f19fb5
>>>>> Author:     David Matlack<[email protected]>
>>>>> AuthorDate: Fri Apr 17 15:14:46 2020 -0700
>>>>> Commit:     Paolo Bonzini<[email protected]>
>>>>> CommitDate: Fri Apr 24 12:53:17 2020 -0400
>>>>>
>>>>>       kvm: add capability for halt polling
>>>>>
>>>>> broke the possibility for an admin to disable halt polling for already running KVM guests.
>>>>> In past times doing
>>>>> echo 0 > /sys/module/kvm/parameters/halt_poll_ns
>>>>>
>>>>> stopped polling system wide.
>>>>> Now all KVM guests will use the halt_poll_ns value that was active during
>>>>> startup - even those that do not use KVM_CAP_HALT_POLL.
>>>>>
>>>>> I guess this was not intended?
>>>
>>> No, but...
>>>
>>>> I would go so far as to say that halt_poll_ns should be a hard limit on
>>>> the capability
>>>
>>> ... this would not be a good idea I think.  Anything that wants to do a lot of polling can just do "for (;;)".
> 
> I agree. It would also be a maintenance burden and subtle "gotcha" to
> have to increase halt_poll_ns anytime one wants to increase
> KVM_CAP_HALT_POLL.

I think the idea of the upper bound is not about preventing wasting CPUs
but to reconfigure existing poll intervals on a global level. So I think
this idea is a bad idea in itself. Especially as the admin might not have
access to the monitor of user QEMUs.

>>>
>>> So I think there are two possibilities that makes sense:
>>>
>>> * track what is using KVM_CAP_HALT_POLL, and make writes to halt_poll_ns follow that
>>
>> what about using halt_poll_ns for those VMs that did not uses KVM_CAP_HALT_POLL and the private number for those that did.
> 
> None of these options would cover Christian's original use-case
> though. (Write to module to disable halt-polling system-wide.)
> 
> What about adding a writable "enable_halt_polling" module parameter

that would then affect both classes with and without KVM_CAP_HALT_POLL.

> that affects all VMs? Once that is in place we could also consider
> getting rid of halt_poll_ns entirely.

As far as I can tell QEMU does not yet use KVM_CAP_HALT_POLL.
So having a system wide halt_poll_ns makes sense. And I think for all
processes not using KVM_CAP_HALT_POLL we should really follow what
halt_poll_ns is NOW and not what it used to be.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.