From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC 0/4] KVM in-kernel PM Timer implementation Date: Tue, 14 Dec 2010 15:46:52 -0600 Message-ID: <4D07E5CC.4040604@codemonkey.ws> References: <901746004.680841292328577685.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4D078D5A.9060804@codemonkey.ws> <4D07B0DB.7010701@cisco.com> <4D07CA3C.2010108@codemonkey.ws> <4D07CB8A.8060600@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ulrich Obergfell , kvm@vger.kernel.org, glommer@redhat.com, zamsden@redhat.com, avi@redhat.com, mtosatti@redhat.com To: "David S. Ahern" Return-path: Received: from mail-qy0-f174.google.com ([209.85.216.174]:38974 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756497Ab0LNVq7 (ORCPT ); Tue, 14 Dec 2010 16:46:59 -0500 Received: by qyj19 with SMTP id 19so5301558qyj.19 for ; Tue, 14 Dec 2010 13:46:58 -0800 (PST) In-Reply-To: <4D07CB8A.8060600@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 01:54 PM, David S. Ahern wrote: > > On 12/14/10 12:49, Anthony Liguori wrote: > >> But that doesn't tell you what the impact is in real world workloads. >> Before we start pushing all device emulation into the kernel, we need to >> quantify how often gettimeofday() is really called in real workloads. >> > The workload that inspired that example program at its current max load > calls gtod upwards of 1000 times per second. The overhead of > gettimeofday was the biggest factor when comparing performance to bare > metal and esx. That's why I wrote the test program --- boils a complex > product/program to a single system call. > So the absolute performance impact was on the order of what? The difference in CPU time of a light weight vs. heavy weight exit should be something like 2-3us. That would mean 2-3ms of CPU time at a rate of 1000 per second. That should be pretty much in the noise. There are possibly second order effects that might make a large impact such as contention with the qemu_mutex. It's worth doing experimentation to see if a non-mutex acquiring fast path in userspace also resulted in a significant performance boost. Regards, Anthony Liguori > David > > >> Regards, >> >> Anthony Liguori >> >> >>> What's the relative speed of the in-kernel pmtimer compared to the PIT? >>> >>> David >>> >>> >>