From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751456AbdIAGwd (ORCPT ); Fri, 1 Sep 2017 02:52:33 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:38135 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751022AbdIAGwa (ORCPT ); Fri, 1 Sep 2017 02:52:30 -0400 X-Google-Smtp-Source: ADKCNb7LUMikyml/5T5rA28Um/zRkYaRA9CDxImGw61tFB3IXfuG9FHeFp1xJ0Zq+1cluHI3fuBM1SH08LJ0t9R57KI= MIME-Version: 1.0 In-Reply-To: References: <1504007201-12904-1-git-send-email-yang.zhang.wz@gmail.com> From: Wanpeng Li Date: Fri, 1 Sep 2017 14:52:28 +0800 Message-ID: Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support To: Yang Zhang Cc: "linux-kernel@vger.kernel.org" , kvm , Wanpeng Li , "Michael S. Tsirkin" , Paolo Bonzini , Thomas Gleixner , Radim Krcmar , David Matlack , Alexander Graf , Peter Zijlstra , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-09-01 14:32 GMT+08:00 Yang Zhang : > 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 > > > 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 same performance as only enable guest side > poll but it will cost more cpu because of poll KVM side. It means we should > disable KVM side poll since it cannot give much improvement than guest side > except consume more cpu and large latency. How can message passing workloads in windows guest survive? 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 >> 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 the one copy currently, we will do it in next version. > > > > -- > Yang > Alibaba Cloud Computing