RE: [Xen-devel] [PATCH] Dont' round-robin the callback interrupt

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

Ok, I can buy that argument to a degree, but in the case of the PV drivers 
*all* our interrupts are multiplexed through a single irq, so we get no benefit 
from round robining which systems using multiple irqs might.

  Paul

> -----Original Message-----
> From: Keir Fraser
> Sent: 12 July 2010 18:18
> To: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Tim Deegan
> Subject: Re: [Xen-devel] [PATCH] Dont' round-robin the callback
> interrupt
> 
> On 12/07/2010 17:36, "Paul Durrant" <Paul.Durrant@xxxxxxxxxx> wrote:
> 
> >   When we connect our platform driver interrupt, Windows is at
> liberty to
> > allocate vectors on as many or as few cpus as it wishes. I've seen
> cases where
> > it will *not* allocate us a vector on vcpu 0, so we cannot force
> vcpu 0. Older
> > frontends assume vcpu 0, but should function ok if the interrupt
> does not move
> > around.
> >   However, that's not the motivation for this patch. In the
> windows code, we
> > only bind event channels to vcpu 0 since we cannot get callback
> interrupts on
> > multiple vcpus simultaneously, since the interrupt is level
> sensitive. Thus
> > round-robining is wasteful in terms of kicking certain data
> structures between
> > caches (assuming a reasonably constant vcpu -> pcpu mapping).
> 
> Surely that argument can be made for any interrupt that is set up to
> round-robin among multiple CPUs? Obviously in the PV drivers case
> the
> event-channel IRQ is probably the only significant source of round-
> robin
> interrupts. But I don't see that it's special in any other way.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel