| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Dont' round-robin the callback interrupt
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
|
|
|
| |
|
Home