From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: kvm@vger.kernel.org, avi@redhat.com, mtosatti@redhat.com
Subject: Re: [PATCH 0/5][RFC] more fine grained locking for IRQ injection
Date: Mon, 13 Jul 2009 17:43:15 +0300 [thread overview]
Message-ID: <20090713144315.GK10402@redhat.com> (raw)
In-Reply-To: <20090713143312.GR28046@redhat.com>
On Mon, Jul 13, 2009 at 05:33:12PM +0300, Gleb Natapov wrote:
> On Mon, Jul 13, 2009 at 05:21:48PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jul 13, 2009 at 04:58:58PM +0300, Gleb Natapov wrote:
> > > On Mon, Jul 13, 2009 at 04:53:15PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 13, 2009 at 04:28:09PM +0300, Gleb Natapov wrote:
> > > > > On Mon, Jul 13, 2009 at 04:23:36PM +0300, Michael S. Tsirkin wrote:
> > > > > > On Mon, Jul 13, 2009 at 12:12:30PM +0300, Gleb Natapov wrote:
> > > > > > > kvm->irq_lock protects too much stuff, but still fail to protect
> > > > > > > everything it was design to protect (see ack notifiers call in pic). I
> > > > > > > want to make IRQ injection logic use more fine grained locking.
> > > > > >
> > > > > > At least irq routing changes and notifier list changes
> > > > > > do not seem to be involved in irq injection.
> > > > > > So why do we want fine-grained locking there?
> > > > > >
> > > > > When you have one big lock and you want to eliminate it you look at all
> > > > > things it protects and you start introducing different locking for
> > > > > unrelated stuff. This is what this patch series does, so I don't really
> > > > > get you point.
> > > >
> > > > But why do you want to eliminate it? What is the operation that this
> > > > will speed up? Is there a contention issue and which operations
> > > > contend on the lock?
> > > >
> > > Interrupt injection. I want to be able to inject interrupts without the
> > > lock at all.
> >
> > You are talking about the lapic changes below, right? OK. But how do
> > the other changes help, specifically? I'm less familiar with ioapic, but
> > I think irq routing and irq notifier list changes are done off data
> > path.
> >
> irq_routing is accessed on irq injection path, so making in lockless is
> necessary to achieve the goal. Making ack notifiers lockless removes one
> lock from EOI path.
But this is done with RCU patches, right?
--
MST
next prev parent reply other threads:[~2009-07-13 14:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-13 9:12 [PATCH 0/5][RFC] more fine grained locking for IRQ injection Gleb Natapov
2009-07-13 9:12 ` [PATCH 1/5] Protect irq_sources_bitmap by kvm->lock instead of kvm->irq_lock Gleb Natapov
2009-07-13 14:29 ` Gregory Haskins
2009-07-13 14:39 ` Gleb Natapov
2009-07-13 14:55 ` Michael S. Tsirkin
2009-07-13 15:01 ` Gleb Natapov
2009-07-13 15:03 ` Gregory Haskins
2009-07-13 15:11 ` Gregory Haskins
2009-07-13 15:19 ` Gleb Natapov
2009-07-13 9:12 ` [PATCH 2/5] Move irq routing to its own locking Gleb Natapov
2009-07-13 9:12 ` [PATCH 3/5] Move irq notifiers lists " Gleb Natapov
2009-07-13 11:45 ` Michael S. Tsirkin
2009-07-13 11:48 ` Gleb Natapov
2009-07-13 14:23 ` Michael S. Tsirkin
2009-07-13 14:37 ` Gleb Natapov
2009-07-13 14:49 ` Michael S. Tsirkin
2009-07-13 15:23 ` Gleb Natapov
2009-07-13 15:32 ` Gregory Haskins
2009-07-13 15:40 ` Michael S. Tsirkin
2009-07-13 16:28 ` Gleb Natapov
2009-07-13 16:23 ` Marcelo Tosatti
2009-07-13 16:31 ` Marcelo Tosatti
2009-07-13 16:35 ` Gleb Natapov
2009-07-13 16:43 ` Marcelo Tosatti
2009-07-13 9:12 ` [PATCH 4/5] Move IO APIC to its own lock Gleb Natapov
2009-07-13 9:12 ` [PATCH 5/5] Drop kvm->irq_lock lock Gleb Natapov
2009-07-13 13:23 ` [PATCH 0/5][RFC] more fine grained locking for IRQ injection Michael S. Tsirkin
2009-07-13 13:28 ` Gleb Natapov
2009-07-13 13:53 ` Michael S. Tsirkin
2009-07-13 13:58 ` Gleb Natapov
2009-07-13 14:21 ` Michael S. Tsirkin
2009-07-13 14:33 ` Gleb Natapov
2009-07-13 14:43 ` Michael S. Tsirkin [this message]
2009-07-13 15:21 ` Gleb Natapov
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=20090713144315.GK10402@redhat.com \
--to=mst@redhat.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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.