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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Yes, if it's possible to make this optimisation in the PV driver itself,
then I think that is the better path.

 -- Keir

On 13/07/2010 09:02, "Paul Durrant" <Paul.Durrant@xxxxxxxxxx> wrote:

> 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