Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754494AbdH2Ogh (ORCPT ); Tue, 29 Aug 2017 10:36:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751331AbdH2Ogf (ORCPT ); Tue, 29 Aug 2017 10:36:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 08B446147F Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mst@redhat.com Date: Tue, 29 Aug 2017 17:36:32 +0300 From: "Michael S. Tsirkin" To: Wanpeng Li 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 Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support 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 Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 29 Aug 2017 14:36:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 823 Lines: 19 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