From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM performance vs. Xen Date: Thu, 30 Apr 2009 18:19:07 +0300 Message-ID: <49F9C16B.9000809@redhat.com> References: <49F8672E.5080507@linux.vnet.ibm.com> <49F967AE.4040905@redhat.com> <49F9AB64.20506@codemonkey.ws> <49F9AEC0.2060909@redhat.com> <49F9AFE6.8010704@linux.vnet.ibm.com> <49F9BF9E.50006@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Theurer , kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53484 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750869AbZD3PTP (ORCPT ); Thu, 30 Apr 2009 11:19:15 -0400 In-Reply-To: <49F9BF9E.50006@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > > Previously, the block API only exposed non-vector interfaces and > bounced vectored operations to a linear buffer. That's been > eliminated now though so we need to update the linux-aio patch to > implement a vectored backend interface. > > However, it is an apples to apples comparison in terms of copying > since the same is true with the thread pool. My take away was that > the thread pool overhead isn't the major source of issues. If the overhead is dominated by copying, then you won't see the difference. Once the copying is eliminated, the comparison may yield different results. We should certainly see a difference in context switches. One cause of context switches won't be eliminated - the non-saturating workload causes us to switch to the idle thread, which incurs a heavyweight exit. This doesn't matter since we're idle anyway, but when we switch back, we incur a heavyweight entry. -- error compiling committee.c: too many arguments to function