Ryan Harper wrote:
I'd rather avoid any additional accounting overhead of a pool.
The accounting overhead is noise compared to copying hundreds of
megabytes per second.
If 4MB
is a reasonable limit, lets make that the new max.
The real max is the dma buffer size multiplied by the number of
concurrent requests. With a queue depth of 64, the buffers become 4 MB
* 64 = 256 MB. That can double the size of a small guest, and using
just one disk, too.
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.
We know what the ideal is: dropping the scatter/gather buffer completely.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
