WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <paul.durrant@xxxxxxxxxx>, <james.harper@xxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL PVdriver
From: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>
Date: Fri, 11 Mar 2011 13:10:03 +0800
Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 10 Mar 2011 21:10:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
Importance: Normal
In-reply-to: <291EDFCB1E9E224A99088639C47620228E936E1AA0@xxxxxxxxxxxxxxxxxxxxxxxxx>
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>, <291EDFCB1E9E224A99088639C47620228E936E1A88@xxxxxxxxxxxxxxxxxxxxxxxxx>, <AEC6C66638C05B468B556EA548C1A77D01C55E8E@trantor>, <291EDFCB1E9E224A99088639C47620228E936E1A9A@xxxxxxxxxxxxxxxxxxxxxxxxx>, <AEC6C66638C05B468B556EA548C1A77D01C55E91@trantor>, <291EDFCB1E9E224A99088639C47620228E936E1AA0@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Paul:
 
      Sorry I'm not fully follow your point.
      One quick question is when you mention "pointless round robin", which piece of code did you refer to?
 
thanks.
 
> From: Paul.Durrant@xxxxxxxxxx
> To: james.harper@xxxxxxxxxxxxxxxx; tinnycloud@xxxxxxxxxxx
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx
> Date: Thu, 10 Mar 2011 11:05:56 +0000
> Subject: RE: [Xen-devel] RE: Rather slow time of Pin in Windows with GPL PVdriver
>
> It's kind of pointless because you're always having to go to vCPU0's shared info for the event info. so you're just going to keep pinging this between caches all the time. Same holds true of data you access in your DPC if it's constantly moving around. Better IMO to keep locality by default and distribute DPCs accessing distinct data explicitly.
>
> Paul
>
> > -----Original Message-----
> > From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
> > Sent: 10 March 2011 10:41
> > To: Paul Durrant; MaoXiaoyun
> > Cc: xen devel
> > Subject: RE: [Xen-devel] RE: Rather slow time of Pin in Windows with
> > G PL PVdriver
> >
> > >
> > > Yeah, you're right. We have a patch in XenServer to just use the
> > lowest
> > > numbered vCPU but in unstable it still pointlessly round robins.
> > Thus,
> > if you
> > > bind DPCs and don't set their importance up you will end up with
> > them
> > not
> > > being immediately scheduled quite a lot of the time.
> > >
> >
> > You say "pointlessly round robins"... why is the behaviour
> > considered pointless? (assuming you don't use bound DPCs)
> >
> > I'm looking at my networking code and if I could schedule DPC's on
> > processors on a round-robin basis (eg because the IRQ's are
> > submitted on a round robin basis), one CPU could grab the rx ring
> > lock, pull the data off the ring into local buffers, release the
> > lock, then process t he local buffers (build packets, submit to NDIS,
> > etc). While the first CPU is processing packets, another CPU can
> > then start servicing the ring too.
> >
> > If Xen is changed to always send the IRQ to CPU zero then I'd have
> > to start round-robining DPC's myself if I wanted to do it that
> > way...
> >
> > Currently I'm suffering a bit from the small ring sizes not being
> > able to hold enough buffers to keep packets flowing quickly in all
> > situations.
> >
> > James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>