Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932102Ab0LRSLh (ORCPT ); Sat, 18 Dec 2010 13:11:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19541 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757141Ab0LRSLf (ORCPT ); Sat, 18 Dec 2010 13:11:35 -0500 Date: Sat, 18 Dec 2010 20:11:00 +0200 From: "Michael S. Tsirkin" To: Thomas Gleixner Cc: Jan Kiszka , Jan Kiszka , Avi Kivity , Marcelo Tosatti , "linux-kernel@vger.kernel.org" , kvm , Tom Lyon , Alex Williamson Subject: Re: [PATCH v3 2/4] genirq: Inform handler about line sharing state Message-ID: <20101218181100.GA2182@redhat.com> References: <4D0A75E3.3090900@web.de> <4D0B1CD9.5060601@web.de> <4D0B3C11.4090307@siemens.com> <4D0B400D.8010903@siemens.com> <4D0B8A73.4050005@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2679 Lines: 59 On Fri, Dec 17, 2010 at 05:32:46PM +0100, Thomas Gleixner wrote: > On Fri, 17 Dec 2010, Jan Kiszka wrote: > > Am 17.12.2010 16:25, Thomas Gleixner wrote: > > > Your aproach with disable_irq_nosync() is completely flawed, simply > > > because you try to pretend that your interrupt handler is done, while > > > it is not done at all. The threaded interrupt handler is done when > > > user space completes. Everything else is just hacking around the > > > problem and creates all that nasty transitional problems. > > > > disable_irq_nosync is the pattern currently used in KVM, it's nothing > > new in fact. > > That does not make it less flawed :) > > > The approach looks interesting but requires separate code for > > non-PCI-2.3 devices, i.e. when we have no means to mask at device level. > > Why? You can have the same code, you just can't request COND_ONESHOT > handlers for it, so it needs unshared ONESHOT or it won't work at all, > no matter what approach you chose. No device level mask, no sharing, > it's that simple. > > > Further drawbacks - unless I missed something on first glance: > > > > - prevents any future optimizations that would work without IRQ thread > > ping-pong (ie. once we allow guest IRQ injection from hardirq context > > for selected but typical setups) > > - two additional, though light-weight, context switches on each > > interrupt completion > > The drawback of these two points is way less than the horror which you > need to introduce to do the whole async handler disable, userspace > enable dance. Robust and simple solutions really a preferred over > complex and fragile horror which has a questionable runtime benefit. I'd like to note that the overhead of involving the scheduler in interrupt injection for an assigned device should be easily measurable: just make the MSI handlers threaded and see what the result is. In the case of emulated devices, when we had an extra thread involved in MSI handling, the vcpu thread and the interrupt injection thread were competing for cpu with strange fluctuations in performance as the result (i.e. sometimes we would get good speed as threading would introduce a kind of interrupt coalescing, sometimes we would get huge latency). > > - continuous polling if user space decides to leave the interrupt > > unhandled (e.g. because the virtual IRQ line is masked) > > That should be a solvable problem. > > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/