From: Gleb Natapov <gleb@redhat.com>
To: Gregory Haskins <gregory.haskins@gmail.com>
Cc: Gregory Haskins <ghaskins@novell.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
alacrityvm-devel@lists.sourceforge.net
Subject: Re: [KVM PATCH 1/2] KVM: Directly inject interrupts via irqfd
Date: Wed, 21 Oct 2009 17:36:40 +0200 [thread overview]
Message-ID: <20091021153640.GS29477@redhat.com> (raw)
In-Reply-To: <4ADF2A1B.3010205@gmail.com>
On Wed, Oct 21, 2009 at 11:34:51AM -0400, Gregory Haskins wrote:
> Gleb Natapov wrote:
> > On Wed, Oct 21, 2009 at 10:34:53AM -0400, Gregory Haskins wrote:
> >> IRQFD currently uses a deferred workqueue item to execute the injection
> >> operation. It was originally designed this way because kvm_set_irq()
> >> required the caller to hold the irq_lock mutex, and the eventfd callback
> >> is invoked from within a non-preemptible critical section.
> >>
> >> With the advent of lockless injection support in kvm_set_irq, the deferment
> >> mechanism is no longer technically needed. Since context switching to the
> >> workqueue is a source of interrupt latency, lets switch to a direct
> >> method.
> >>
> > kvm_set_irq is fully lockless only in MSI case. IOAPIC/PIC has mutexes.
>
> Right, but irqfd by design only works with MSI (or MSI like edge
> triggers) anyway. Legacy-type injections follow a different path.
>
Ah, If this the case and it will stay that way then the change looks OK
to me.
> In any case, I didn't change the locking (you did ;). You recently
> patched the irqfd code to remove the irq_lock, but we still had the
> deferment mechanism in place to avoid the mutex_lock from within the
> POLLIN callback. Since the mutex_lock is now no longer acquired in this
> path, the deferment technique is not needed either. Its only adding
> overhead for no purpose. So I am simply cleaning that up to improve
> interrupt performance.
>
> HTH,
> -Greg
>
>
--
Gleb.
next prev parent reply other threads:[~2009-10-21 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-21 14:34 [KVM PATCH 0/2] irqfd enhancements Gregory Haskins
2009-10-21 14:34 ` [KVM PATCH 1/2] KVM: Directly inject interrupts via irqfd Gregory Haskins
2009-10-21 15:26 ` Gleb Natapov
2009-10-21 15:34 ` Gregory Haskins
2009-10-21 15:36 ` Gleb Natapov [this message]
2009-10-21 15:42 ` Gregory Haskins
2009-10-22 15:07 ` Avi Kivity
2009-10-22 15:14 ` Gregory Haskins
2009-10-22 15:19 ` Avi Kivity
2009-10-22 15:33 ` Gregory Haskins
2009-10-21 14:34 ` [KVM PATCH 2/2] KVM: Remove unecessary irqfd-cleanup-wq Gregory Haskins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091021153640.GS29477@redhat.com \
--to=gleb@redhat.com \
--cc=alacrityvm-devel@lists.sourceforge.net \
--cc=ghaskins@novell.com \
--cc=gregory.haskins@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.