From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support Date: Tue, 29 Aug 2017 17:36:32 +0300 Message-ID: <20170829172929-mutt-send-email-mst@kernel.org> References: <1504007201-12904-1-git-send-email-yang.zhang.wz@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yang Zhang , "linux-kernel@vger.kernel.org" , kvm , Wanpeng Li , Paolo Bonzini , Thomas Gleixner , Radim Krcmar , David Matlack , Alexander Graf , Peter Zijlstra , linux-doc@vger.kernel.org To: Wanpeng Li Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-doc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Tue, Aug 29, 2017 at 10:02:15PM +0800, Wanpeng Li wrote: > 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 fact, I would really like to better understand why does the polling in kvm even help. Switching to the idle task is supposed to be really cheap as you are not losing context. In case of e.g. network polling you gain the interrupt latency, but in case of kvm it's just an IPI which is converted to a memory write when using mwait. Is mwait more costly than commonly thought? Or is the idle driver too agressive in putting the CPU into deep sleep? I think this analysis is something that would benefit bare-metal/containers as well. -- MST