Re: assign-dev: Purpose of interrupt_work

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]