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 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. ...but require scheduler activity in case of dev-passthrough, which is surely playing in a different league. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
