RE: [Xen-devel] more profiling

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 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