From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: [RFC][PATCH 1/3] Introduce a workqueue to deliver PIT timer interrupts. Date: Thu, 10 Jun 2010 09:17:30 -1000 Message-ID: <4C113A4A.1030103@redhat.com> References: <1276019703-18136-1-git-send-email-clalance@redhat.com> <1276019703-18136-2-git-send-email-clalance@redhat.com> <4C0EFE20.1080508@redhat.com> <20100609132335.GA7396@amt.cnet> <4C1004F5.3020703@redhat.com> <4C10AF41.6080600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Chris Lalancette , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53759 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752068Ab0FJTRd (ORCPT ); Thu, 10 Jun 2010 15:17:33 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5AJHWui002618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Jun 2010 15:17:32 -0400 In-Reply-To: <4C10AF41.6080600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/09/2010 11:24 PM, Avi Kivity wrote: > On 06/10/2010 12:17 AM, Zachary Amsden wrote: >> On 06/09/2010 03:23 AM, Marcelo Tosatti wrote: >>> On Tue, Jun 08, 2010 at 04:36:16PM -1000, Zachary Amsden wrote: >>>>> + pt->timer.function = pit_timer_fn; >>>>> >>>> I am happy to see this. I thought kvm_timer_fn was a step >>>> backwards; it was too general of a function to justify the savings >>>> of 20 some odd lines of code. >>> This was not done to save 20 lines of code: >>> >>> http://www.mail-archive.com/kvm@vger.kernel.org/msg18640.html >>> >>>> Is there any chance that using a workqueue might help the problem of >>>> hrtimers firing too quickly? I wanted to return HR_NORESTART from >>>> pit_timer_fn always, then restart the hrtimer on delivery, but >>>> because of unreliable delivery, it wasn't clear how to do that. >>>> >>>> Perhaps the workqueue can be used to restart the timer instead, >>>> avoiding problems of impossibly small timeouts causing hrtimers to >>>> run amok. >>> It should be rearmed on ACK ideally. How come delivery is unreliable? >> >> Due to the various ways IRQ can be latched or not with different >> routing. If you program a very short timeout, it should fire even if >> the guest is slow to respond: >> >> i..i..i..i..i..i..i >> ..a...a...a...a >> >> if you don't restart right away, only on ack, you can risk the refire >> of the interrupt getting lost, especially if the guest happens to >> reprogram the PIT while this is happening... >> > > Restarting on ack has the big advantage of not rearming at all if the > guest doesn't ack, i.e. a timer left running talking to a masked irq pin. > Exactly... it scales too, with how fast we can manage to deliver the interrupts. We just have to be sure we don't drop the re-fire completely in any race conditions. Some stress will be required. Zach