From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: assign-dev: Purpose of interrupt_work Date: Mon, 12 Oct 2009 10:16:56 +0200 Message-ID: <4AD2E5F8.4070107@web.de> References: <4AD2D4B6.7030203@web.de> <20091012071310.GT16702@redhat.com> <4AD2DA57.6030006@web.de> <20091012074513.GV16702@redhat.com> <4AD2DFE2.4050406@web.de> <20091012075715.GW16702@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2DCE616B9B0AAE5617B0172" Cc: Avi Kivity , kvm-devel To: Gleb Natapov Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:52340 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754370AbZJLIRn (ORCPT ); Mon, 12 Oct 2009 04:17:43 -0400 In-Reply-To: <20091012075715.GW16702@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE2DCE616B9B0AAE5617B0172 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Mon, Oct 12, 2009 at 09:50:58AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Mon, Oct 12, 2009 at 09:27:19AM +0200, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> On Mon, Oct 12, 2009 at 09:03:18AM +0200, Jan Kiszka wrote: >>>>>> Hi, >>>>>> >>>>>> I was starring at the IRQ delivery path of assigned devices for a = while, >>>>>> wondering why we have a work queue there. Now, after looking at so= me >>>>>> prehistoric versions, I think the reason is that there once was a = mutex >>>>>> involved while we now use RCU. Am I right that we could actually d= rop >>>>>> this indirection today? >>>>>> >>>>> ioapic/pic path still has mutex. If MSIX is used (like it should) w= e can >>>>> drop work queue. >>>> I see. Wouldn't it be feasible to convert the fast paths of [io]apic= to >>>> spinlocks? >>>> >>> Apic is lockless. For ioapic/pic I used spinlocks initially, but Avi >>> prefers mutexes. Theoretically it is possible to make them lockless, >>> but code will be complex and eventually more slow, since more then tw= o >>> atomic operation will be used on irq injection path. >> Well, lockless is another thing. >> >> But also converting to spinlocks would indeed add some overhead: >> irqsave/restore. But I wonder if this isn't worth it, at least when >> looking at the (supposed to be fast) device passthrough scenario which= >> would be simpler and faster. >> > Avi's point in favor of mutex is: they are as fast as spinlocks when > congested and allows preemption when held. =2E..but require scheduler activity in case of dev-passthrough, which is surely playing in a different league. Jan --------------enigE2DCE616B9B0AAE5617B0172 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkrS5f8ACgkQitSsb3rl5xQFlQCdGN7yCNG6y9iSx5KPEZeNT/QS LTEAniXsL7el1vwRLjZBQ6Vw3t9ZUrvp =s5Yl -----END PGP SIGNATURE----- --------------enigE2DCE616B9B0AAE5617B0172--