Re: assign-dev: Purpose of interrupt_work

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

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]