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 22:44:55 +0200 Message-ID: <4AD39547.6070506@web.de> References: <4AD2D4B6.7030203@web.de> <20091012071310.GT16702@redhat.com> <4AD2DA57.6030006@web.de> <20091012074513.GV16702@redhat.com> <4AD2DFE2.4050406@web.de> <4AD2EB2D.5080909@redhat.com> <4AD2F1D0.4090005@web.de> <20091012173651.GA3923@amt.cnet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD435BCCEA95CFC2BECF9231C" Cc: Avi Kivity , Gleb Natapov , kvm-devel To: Marcelo Tosatti Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:53993 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802AbZJLUrd (ORCPT ); Mon, 12 Oct 2009 16:47:33 -0400 In-Reply-To: <20091012173651.GA3923@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD435BCCEA95CFC2BECF9231C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marcelo Tosatti wrote: > On Mon, Oct 12, 2009 at 11:07:28AM +0200, Jan Kiszka wrote: >> Avi Kivity wrote: >>> On 10/12/2009 09:50 AM, Jan Kiszka wrote: >>>>> Apic is lockless. For ioapic/pic I used spinlocks initially, but Av= i >>>>> prefers mutexes. Theoretically it is possible to make them lockless= , >>>>> but code will be complex and eventually more slow, since more then = two >>>>> atomic operation will be used on irq injection path. >>>>> =20 >>>> 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 whi= ch >>>> would be simpler and faster. >>>> =20 >>> I'm worried about disabling irqs for non-device-assignment cases. It= >>> would be more palatable if ioapic was completely O(1) (there are some= >>> per-vcpu loops in there, shouldn't be too bad for 16 vcpus, but we wa= nt >>> to scale). >> Yeah, what a pity. That's likely not solvable in a generic way, given >> that the guest finally decided how many VCPUs may listen to a line. >> >> OK, but dropping interrupt_work from the MSI path is still worthwhile,= >> and probably more future-proof anyway. >=20 > Seems appropriate to convert the process context work to threaded > interrupt (instead of workqueue). That should help latency. >=20 Not for the trivial case (I want to avoid scheduling as far as possible).= Jan --------------enigD435BCCEA95CFC2BECF9231C 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 iEYEARECAAYFAkrTlVIACgkQitSsb3rl5xSL8wCgz/67lUz+i2ZKvsZIhOMd8GpF ndEAoIlzKvu093n1vjOVOwcDHRfdJzNf =lx2E -----END PGP SIGNATURE----- --------------enigD435BCCEA95CFC2BECF9231C--