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 some > >>>> 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 drop > >>>> this indirection today? > >>>> > >>> ioapic/pic path still has mutex. If MSIX is used (like it should) we 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 two > > 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. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
