From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Ahern" Subject: Re: [PATCH] kvm-userspace: Make PC speaker emulation aware of in-kernel PIT Date: Mon, 27 Apr 2009 22:44:35 -0600 Message-ID: <49F689B3.6090109@cisco.com> References: <49F0CE65.4050005@web.de> <20090425001319.GB15144@amt.cnet> <49F30B55.6050207@codemonkey.ws> <49F33A1A.3060201@web.de> <49F36B8F.2090405@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Marcelo Tosatti , Avi Kivity , kvm-devel To: Anthony Liguori Return-path: Received: from sj-iport-6.cisco.com ([171.71.176.117]:30501 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbZD1Eoh (ORCPT ); Tue, 28 Apr 2009 00:44:37 -0400 In-Reply-To: <49F36B8F.2090405@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Jan Kiszka wrote: >> Anthony Liguori wrote: >> >>> Marcelo Tosatti wrote: >>> >>>> Jan, >>>> >>>> While the patch itself looks fine, IMO it would be better to move all >>>> of the timer handling to userspace, except the performance critical >>>> parts, >>>> since most of it is generic. Either periodic or one-shot timer, with: >>>> >>> The reason for having the PIT in-kernel is not performance. The PIT is >>> not performance sensitive. >>> >> >> I think that depends. Some OSes (in some configurations) use the PIT >> counter as clock source and/or program it regularly in one-shot mode. An >> aging use case, but still a valid one. >> > > I can't find the thread, but this has been discussed at length before. > The justification has always been for time drift correction. If you > crunch the numbers, even at a 1024HZ, there just aren't enough exits to > really make a difference from a performance perspective. > > Just to state it more clearly, if you assume an additional 5us to drop > to userspace (which is absurdly high, but let's stick with it), 1024 > exits per second comes out to about 5ms which is only 0.5% in terms of > CPU consumption. You are considering timekeeping activities only. RHEL4 for example reads the PIT for each gettimeofday call. For applications that add timestamps to logging the PIT is a *HUGE* overhead (and the PMTMR for that matter). I have one example where something like 15% of each second is wasted handling the ioport reads and writes for get_offset_pit. david > > The APIC is quite a bit more understandable because especially with SMP, > you can generate a very high number of interrupts per second and taking > a drop to userspace for every EOI can be start to matter with exit rates > in the hundreds of thousands. > >>> It's because it was easier to do interrupt catch-up by pushing the PIT >>> into the kernel which IMHO was the wrong path to go down. >>> >> >> Pushing the emulation of port 0x61 into the kernel was a mistake we now >> have to deal with. I'm not that sure about the PIT itself. >> > > I agree re: port 0x61. I'm just saying that there is no point in moving > just the non "performance critical" components to userspace as Marcelo > suggests because the whole thing is non "performance critical". > > Regards, > > Anthony Liguori > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >