Re: assign-dev: Purpose of interrupt_work

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

 



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.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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