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: Wed, 09 Jun 2010 11:17:41 -1000 Message-ID: <4C1004F5.3020703@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Lalancette , kvm@vger.kernel.org, avi@redhat.com To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13768 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756653Ab0FIVRo (ORCPT ); Wed, 9 Jun 2010 17:17:44 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o59LHi62029525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jun 2010 17:17:44 -0400 In-Reply-To: <20100609132335.GA7396@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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... Of course, it can be tracked properly, but it requires quite a few more state variables and some careful reasoning to make sure it doesn't drop irqs. This patch series looks as if it will make that sort of reasoning easier to do :) > BTW, a massive amount of hrtimers (_single_ non-tickless 32-vcpu guest > with LAPIC) results in: > > hrtimer: interrupt took 122448 ns > > in the host. So don't even need impossibly small timeouts :( > 32-vcpu on how many pcpu?