[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170829172929-mutt-send-email-mst@kernel.org>
Date: Tue, 29 Aug 2017 17:36:32 +0300
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Wanpeng Li <kernellwp@...il.com>
Cc: Yang Zhang <yang.zhang.wz@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kvm <kvm@...r.kernel.org>, Wanpeng Li <wanpeng.li@...mail.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
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
Powered by blists - more mailing lists