Re: assign-dev: Purpose of interrupt_work

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

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

Marcelo Tosatti wrote:
> On Mon, Oct 12, 2009 at 11:07:28AM +0200, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>> On 10/12/2009 09:50 AM, Jan Kiszka wrote:
>>>>> 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.
>>>>    
>>> I'm worried about disabling irqs for non-device-assignment cases.  It
>>> would be more palatable if ioapic was completely O(1) (there are some
>>> per-vcpu loops in there, shouldn't be too bad for 16 vcpus, but we want
>>> to scale).
>> Yeah, what a pity. That's likely not solvable in a generic way, given
>> that the guest finally decided how many VCPUs may listen to a line.
>>
>> OK, but dropping interrupt_work from the MSI path is still worthwhile,
>> and probably more future-proof anyway.
> 
> Seems appropriate to convert the process context work to threaded
> interrupt (instead of workqueue). That should help latency.
> 

Not for the trivial case (I want to avoid scheduling as far as possible).

Jan


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