| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] Dont' round-robin the callback interrupt
No, I think that's getting a little too ugly. It looks like I can't have a
solution that both caters for older 'broken' frontends and new ones too. I
guess we'll just keep the patch in XS for the next release and I'll fix the
frontends to affinitize to only one vcpu for subsequent releases.
Paul
> -----Original Message-----
> From: Juergen Gross [mailto:juergen.gross@xxxxxxxxxxxxxx]
> Sent: 13 July 2010 06:00
> To: Keir Fraser
> Cc: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxx; Tim Deegan
> Subject: Re: [Xen-devel] [PATCH] Dont' round-robin the callback
> interrupt
>
> On 07/12/2010 07:41 PM, Keir Fraser wrote:
> > On 12/07/2010 18:17, "Keir Fraser"<keir.fraser@xxxxxxxxxxxxx>
> wrote:
> >
> >>> 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.
> >
> > Further, the correct semantics for LowestPrio delivery was
> implemented by
> > Juergen Gross at Fujitsu for a reason. Cc'ing him. I suspect he
> will say
> > that relaxing the delivery semantics will cause something he cares
> about to
> > break.
>
> Thanks for CC'ing me, Keir.
> Selecting different CPUs gives at least our BS2000 system a
> performance win of
> a few percent. As Keir already said, that's the reason I implemented
> the LPP
> delivery of interrupts.
> If you really need a different interrupt delivery behaviour I would
> at least
> recommend a per-domain parameter for violating the correct semantics
> using the
> LPP delivery as default.
>
>
> Juergen
>
> --
> Juergen Gross Principal Developer Operating Systems
> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222
> 2967
> Fujitsu Technology Solutions e-mail:
> juergen.gross@xxxxxxxxxxxxxx
> Domagkstr. 28 Internet: ts.fujitsu.com
> D-80807 Muenchen Company details:
> ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home