Re: assign-dev: Purpose of interrupt_work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux