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

[Ryan Harper]

* Anthony Liguori <address@hidden> [2008-10-04 17:28]:
> Ryan Harper wrote:
> >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?
> >  
> 
> There are two concerns with allowing the guest to alloc arbitrary 
> amounts of memory.  The first is that QEMU is not written in such a way 
> to be robust in the face of out-of-memory conditions so if we run out of 
> VA space, an important malloc could fail and we'd fall over.

That is an understandable concern and I don't want to make matters
worse, even if the instability already exists in the code as-is.  I think
I'd like to see this fail in practice before I'm really concerned.  For
64-bit builds, is the VA space an issue?

> 
> The second concern is that if a guest can allocate arbitrary amounts of 
> memory, it could generate a swap storm.  Unfortunately, AFAIK, Linux is 
> not yet to a point where it can deal with swap fairness.  Hopefully this 
> is a limitation that the IO controller folks are taking into account.

Sure, but as I mentioned, the amount of memory it can allocate can
surely be controlled by the host system per-process ulimit no?


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