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] more profiling

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>, Andy Grover <andy.grover@xxxxxxxxxx>
Subject: RE: [Xen-devel] more profiling
From: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
Date: Fri, 29 Feb 2008 17:30:03 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Feb 2008 09:31:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D0131AF34@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D0131AF31@trantor> <AEC6C66638C05B468B556EA548C1A77D0131AF34@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ach6wj+maafveOiCSzitY54bCV1UyQAFngGQAAfOF9A=
Thread-topic: [Xen-devel] more profiling

Could you please provide me some context and details of this work.
This seems related to the work we are doing in netchannel2 to reuse grants, but 
I don't think I understand what is that you are trying to do and how it is 



> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> James Harper
> Sent: Friday, February 29, 2008 5:45 AM
> To: James Harper; Andy Grover
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] more profiling
> > What I'd like to do is implement a compromise between my previous
> buffer
> > management approach (used lots of memory, but no allocate/grant per
> > packet) and your approach (uses minimum memory, but
> allocate/grant per
> > packet). We would maintain a pool of packets and buffers,
> and grow and
> > shrink the pool dynamically, as follows:
> > . Create a freelist of packets and buffers . When we need a
> new packet
> > or buffer, and there are none on the freelist, allocate
> them and grant
> > the buffer.
> > . When we are done with them, put them on the freelist .
> Keep a count
> > of the minimum size of the freelists. If the free list has been
> > greater than some value (32?) for some time (5 seconds?) then free
> > half of the items on the list.
> > . Maybe keep a freelist per processor too, to avoid the need for
> > spinlocks where we are running at DISPATCH_LEVEL
> >
> > I think that gives us a pretty good compromise between memory usage
> and
> > calls to allocate/grant/ungrant/free.
> I have implemented something like the above, a 'page pool'
> which is a list of pre-granted pages. This drops the time
> spent in TxBufferGC and SendQueuedPackets by 30-50%. A good
> start I think, although there doesn't appear to be much
> improvement in the iperf results, maybe only 20%.
> It's time for sleep now, but when I get a chance I'll add the
> same logic to the receive path, and clean it up so xennet can
> unload properly (currently it leaks and/or crashes on unload).
> 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>