Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754225AbdH2O1w (ORCPT ); Tue, 29 Aug 2017 10:27:52 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:33312 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753075AbdH2O1u (ORCPT ); Tue, 29 Aug 2017 10:27:50 -0400 Date: Tue, 29 Aug 2017 10:27:06 -0400 From: Konrad Rzeszutek Wilk To: Wanpeng Li Cc: Yang Zhang , "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 Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support Message-ID: <20170829142706.GN32175@char.us.oracle.com> References: <1504007201-12904-1-git-send-email-yang.zhang.wz@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1965 Lines: 43 On Tue, Aug 29, 2017 at 10:02:15PM +0800, 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 "real workload like netperf"? That is not a real workload. That is a synthetic one. > patchset and the adaptive halt-polling logic in kvm simultaneously can > result in more cpu power consumption. I remembered that David from > 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 More CPU power consumption sounds as a bad idea, does it not? > acceptable by maintainer, I will introduce the generic adaptive > halt-polling framework in kvm to avoid the duplicate logic. > > Regards, > Wanpeng Li