[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: James Harper <james.harper@xxxxxxxxxxxxxxxx>, MaoXiaoyun <tinnycloud@xxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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.

  Paul

> -----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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.