From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC 0/4] KVM in-kernel PM Timer implementation Date: Tue, 14 Dec 2010 15:34:16 +0200 Message-ID: <4D077258.9030500@redhat.com> References: <901746004.680841292328577685.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, glommer@redhat.com, zamsden@redhat.com, mtosatti@redhat.com To: Ulrich Obergfell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241Ab0LNNeU (ORCPT ); Tue, 14 Dec 2010 08:34:20 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBEDYJ7Q002841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Dec 2010 08:34:19 -0500 In-Reply-To: <901746004.680841292328577685.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 02:09 PM, Ulrich Obergfell wrote: > Hi, > > This is an RFC through which I would like to get feedback on how the > idea of in-kernel PM Timer would be received. > > The current implementation of PM Timer emulation is 'heavy-weight' > because the code resides in qemu userspace. Guest operating systems > that use PM Timer as a clock source (for example, older versions of > Linux that do not have paravirtualized clock) would benefit from an > in-kernel PM Timer emulation. > > Parts 1 thru 4 of this RFC contain experimental source code which > I recently used to investigate the performance benefit. In a Linux > guest, I was running a program that calls gettimeofday() 'n' times > in a loop (the PM Timer register is read during each call). With > in-kernel PM Timer, I observed a significant reduction of program > execution time. > > The experimental code emulates the PM Timer register in KVM kernel. > All other components of ACPI PM remain in qemu userspace. Also, the > 'timer carry interrupt' feature is not implemented in-kernel. If a > guest operating system needs to enable the 'timer carry interrupt', > the code takes care that PM Timer emulation falls back to userspace. > However, I think the design of the code has sufficient flexibility, > so that anyone who would want to add the 'timer carry interrupt' > feature in-kernel could try to do so later on. > What is the motivation for this? Are there any important guests that use the pmtimer? If anything I'd expect hpet or the Microsoft synthetic timers to be a lot more important. -- error compiling committee.c: too many arguments to function