On Saturday 04 October 2008, Anthony Liguori wrote: > Paul Brook wrote: > > On Friday 03 October 2008, Ryan Harper wrote: > >> The default buffer size breaks up larger read/write requests > >> unnecessarily. When we encounter requests larger than the default dma > >> buffer, reallocate the buffer to support the request. > > > > Allocating unboundedly large host buffers based on guest input seems like > > a bad idea. > > Perhaps they could be at least bound to phys_ram_size.
That's still way too large. It means that the maximum host footprint of qemu is many times the size of the guest RAM. There's a good chance that the host machine doesn't even have enough virtual address space to satisfy this request. I expect that the only situation where you can only avoid breaking up large transfers when you have zero-copy IO. Previous zero-copy/vectored IO patches suffered from a similar problem: It is not acceptable to allocate huge chunks of host ram when you fallback to normal IO. > 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. Qemu is perfectly capable of handling large IO requests by splitting them into multiple smaller requests. Enlarging the size of this buffer is just a secondary performance optimisation. Admittedly we don't currently limit the number of simultaneous commands a guest can submit, but that's relatively easy to fix. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
