Re: [Qemu-devel] [PATCH 4/4] Reallocate dma buffers in read/write path if needed

[Ryan Harper <ryanh@us.ibm.com>]

* aliguori@linux.ibm.com <aliguori@linux.ibm.com> [2008-10-04 12:58]:
> Quoting Avi Kivity <avi@redhat.com>:
> 
> >Anthony Liguori wrote:
> >>In general, I don't think there's a correct size to bound them   
> >>that's less than phys_ram_size.  The guest may be issuing really   
> >>big IO requests.
> >
> >The correct fix is not to buffer at all but use scatter-gather.  Until
> >this is done buffering has to be bounded.
> 
> Instead of capping each request at a certain relatively small size and  
> capping the number of requests, I think if we had a cap that was the  
> total amount of outstanding IO, that would give us good performance  
> while not allowing the guest to do anything crazy.
> 
> For instance, a 4MB pool would allow decent sized requests without  
> letting the guest allocate an absurd amount of memory.

I'd rather avoid any additional accounting overhead of a pool.  If 4MB
is a reasonable limit, lets make that the new max.  I can do some
testing to see where we drop off on performance improvements.  We'd
have a default buffer size (smaller than the previous 64, and now 128k
buf size) that is used when we allocate scsi requests; scanning through
send_command() provides a good idea of other scsi command buf usage; and
on reads and writes, keep the capping logic we've had all along, but
bump the max size up to something like 4MB -- or whatever tests results
show as being ideal. 

In all, it seems silly to worry about this sort of thing since the
entire process could be contained with process ulimits if this is really
a concern.  Are we any more concerned that by splitting the requests
into many smaller requests that we're wasting cpu, pegging the
processor to 100% in some cases?

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com