This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL PV drive

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>, MaoXiaoyun <tinnycloud@xxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL PV driver
From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date: Thu, 10 Mar 2011 09:27:08 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 10 Mar 2011 01:27:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01C55E87@trantor>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BLU157-w6170D9B9C6DC4E4CF04C2FDAC90@xxxxxxx>, <D271C3A4-9B27-4E08-A92A-D55A811736EC@xxxxxxxxxxxxxxxx> <BLU157-w82233DE21FFA3AC07FCC3DAC90@xxxxxxx>, <AEC6C66638C05B468B556EA548C1A77D01C55DCB@trantor> <BLU157-w58A3CAD3FBB61D96ABE7CCDAC90@xxxxxxx>, <AEC6C66638C05B468B556EA548C1A77D01C55DCF@trantor> <BLU157-w54789B64D3FF1F57924AD2DAC80@xxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01C55E87@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acve3kAiJZJduml+Qr66YN40iA+eswAAJ3MgAAjparA=
Thread-topic: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL PV driver
You have to be careful here. Xen will only ever deliver the evtchn interrupt to 
VCPU0. I can't immediately see anything preventing an HVM domain trying to bind 
and evtchn to another VCPU but you can see from the code in 
hvm_assert_evtchn_irq() that the guest will only be kicked for events bound to 
VCPU0 (is_hvm_pv_evtchn_vcpu() will only be true for Linux PVonHVM domains). 
Thus if you bind your DPC to a CPU other than zero and don't set it to 
HighImportance then it will not be immediately scheduled since default DPC 
importance is MediumImportance.


> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> Sent: 10 March 2011 06:27
> To: MaoXiaoyun
> Cc: xen devel
> Subject: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL
> PV driver
> >
> > It looks like KeSetTargetProcessorDpc(&xi->rx_dpc, 0) set the
> rx_dpc
> in VCPU0
> > only,
> > and in fact interrput for xennet are distributed across all VCPUS.
> >
> > By using IntFiltr from http://support.microsoft.com/kb/252867
> > to set interrupt affinity to VCPU0 only, without
> KeSetTargetProcessorDpc
> > commentted, we get quite stable ping time too., which is less than
> 1ms
> >
> > So I think this is the problem.
> >  KeSetTargetProcessorDpc should be discard.
> >
> Ah. So when the cpu for the irq is different to the cpu for the dpc,
> you get the extra delay. That makes sense. It would also explain why
> XP didn't seem to see the same problem as I think the IRQ is
> directed to
> CPU0 there... I've been looking for the docs on what's different and
> can't find anything.
> If you can confirm that you have no problems with removing
> KeSetTargetProcessorDpc I'll remove it, at least for >W2003 builds
> until I find the docs about what NDIS expects to do on what CPU.
> James
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>