Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support

From: Wanpeng Li
Date: Fri Sep 01 2017 - 02:58:23 EST


2017-09-01 14:44 GMT+08:00 Yang Zhang <yang.zhang.wz@xxxxxxxxx>:
> On 2017/8/29 22:02, Wanpeng Li wrote:
>>>
>>> Here is the data we get when running benchmark netperf:
>>>
>>> 2. w/ patch:
>>> halt_poll_threshold=10000 -- 15803.89 bits/s -- 159.5 %CPU
>>> halt_poll_threshold=20000 -- 15899.04 bits/s -- 161.5 %CPU
>>> halt_poll_threshold=30000 -- 15642.38 bits/s -- 161.8 %CPU
>>> halt_poll_threshold=40000 -- 18040.76 bits/s -- 184.0 %CPU
>>> halt_poll_threshold=50000 -- 18877.61 bits/s -- 197.3 %CPU
>>>
>>> 3. kvm dynamic poll
>>> halt_poll_ns=10000 -- 15876.00 bits/s -- 172.2 %CPU
>>> halt_poll_ns=20000 -- 15602.58 bits/s -- 185.4 %CPU
>>> halt_poll_ns=30000 -- 15930.69 bits/s -- 194.4 %CPU
>>> halt_poll_ns=40000 -- 16413.09 bits/s -- 195.3 %CPU
>>> halt_poll_ns=50000 -- 16417.42 bits/s -- 196.3 %CPU
>>>
>>
>> Actually I'm not sure how much sense it makes to introduce this pv
>> stuff and the duplicate adaptive halt-polling logic as what has
>> already been done in kvm w/o obvious benefit for real workload like
>> netperf. In addition, as you mentioned offline to me, enable both the
>> patchset and the adaptive halt-polling logic in kvm simultaneously can
>> result in more cpu power consumption. I remembered that David from
>
>
> No.If we use poll in KVM side, it will consume more cpu than in guest side.
> If use both two, then we can get the performance as only enable guest side
> poll but it will cost more cpu because of poll in KVM side. It means we
> should disable KVM side poll since it cannot give much improvement than
> guest side except consume more cpu.

The customers should have enough knowledge about what's the meaning of
the tunning which you exposed.

Regards,
Wanpeng Li

>
>> Google mentioned that Windows Event Objects can get 2x latency
>> improvement in KVM FORUM, which means that the adaptive halt-polling
>> in kvm should be enabled by default. So if the windows guests and
>> linux guests are mixed on the same host, then this patchset will
>> result in more cpu power consumption if the customer enable the
>> polling in the linux guest. Anyway, if the patchset is finally
>
>
> I have said in last time, there already users using idle=poll in there VM,
> you *cannot* prevent them doing it. This patch provide a better solution
> than unconditional poll, we didn't introduce any worse stuff.
>
>> acceptable by maintainer, I will introduce the generic adaptive
>> halt-polling framework in kvm to avoid the duplicate logic.
>
>
> We will add more conditions than the current algorithm in future. But it's
> ok to use one code currently, we will do it in next version.
>
>>
>> Regards,
>> Wanpeng Li
>>
>
>
> --
> Yang
> Alibaba Cloud Computing