From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM performance vs. Xen Date: Thu, 30 Apr 2009 10:59:42 -0500 Message-ID: <49F9CAEE.5070609@codemonkey.ws> 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> <49F9C16B.9000809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Theurer , kvm-devel To: Avi Kivity Return-path: Received: from an-out-0708.google.com ([209.85.132.248]:59536 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756013AbZD3P7p (ORCPT ); Thu, 30 Apr 2009 11:59:45 -0400 Received: by an-out-0708.google.com with SMTP id d40so1372978and.1 for ; Thu, 30 Apr 2009 08:59:45 -0700 (PDT) In-Reply-To: <49F9C16B.9000809@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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. Yes, I agree with this. The absence of copying (in both the thread pool and linux-aio) could yield significantly different results. Regards, Anthony Liguori > 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. >