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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANRm+Cwc38jJwCO1t77J88ep5yuJosPdV35hMBTdiiyxuJinfg@mail.gmail.com>
Date:   Fri, 1 Sep 2017 14:58:18 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Yang Zhang <yang.zhang.wz@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>, Wanpeng Li <wanpeng.li@...mail.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Radim Krcmar <rkrcmar@...hat.com>,
        David Matlack <dmatlack@...gle.com>,
        Alexander Graf <agraf@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-doc@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support

2017-09-01 14:44 GMT+08:00 Yang Zhang <yang.zhang.wz@...il.com>:
> 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