From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [RFC][PATCH 1/3] Introduce a workqueue to deliver PIT timer interrupts. Date: Thu, 10 Jun 2010 13:18:11 -0300 Message-ID: <20100610161811.GA5191@amt.cnet> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Lalancette , kvm@vger.kernel.org, avi@redhat.com To: Zachary Amsden Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19416 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752056Ab0FJQSh (ORCPT ); Thu, 10 Jun 2010 12:18:37 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5AGIbtn025386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Jun 2010 12:18:37 -0400 Content-Disposition: inline In-Reply-To: <4C1004F5.3020703@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 09, 2010 at 11:17:41AM -1000, 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... > > 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? 8