On Wed, Jul 18, 2012 at 9:12 AM, Asias He <asias@xxxxxxxxxx> wrote: > On 07/17/2012 07:11 PM, Stefan Hajnoczi wrote: >> >> On Tue, Jul 17, 2012 at 10:21 AM, Asias He <asias@xxxxxxxxxx> wrote: >>> >>> On 07/17/2012 04:52 PM, Paolo Bonzini wrote: >>>> >>>> >>>> Il 17/07/2012 10:29, Asias He ha scritto: >>>>> >>>>> >>>>> So, vhost-blk at least saves ~6 syscalls for us in each request. >>>> >>>> >>>> >>>> Are they really 6? If I/O is coalesced by a factor of 3, for example >>>> (i.e. each exit processes 3 requests), it's really 2 syscalls per >>>> request. >>> >>> >>> >>> Well. I am counting the number of syscalls in one notify and response >>> process. Sure the IO can be coalesced. >> >> >> Linux AIO also supports batching in io_submit() and io_getevents(). >> Depending on the request pattern in the vring when you process it, you >> should be able to do better than 1 set of syscalls per host I/O >> request. >> >> Are you taking advantage of that at the moment in your userspace >> benchmark? > > > OK. I know that batching in io_submit() and io_getevetns(). There was a > patch for kvm tool long time ago. Now, both vhost-blk and kvm tool are not > taking advantage of that atm. There are issues: e.g. How many number of > request we want to batch? Does this batching hurt latency? I didn't mean introducing a delay so that multiple requests can be batched. I was just thinking of the simple case: when there are a lot of parallel requests the chance increases that a single vring interrupt provides several I/O requests. In that case it's easy for the virtio-blk implementation to issue them all in one io_submit(2) call. The same is true for io_getevents(2), there might be several completed host I/O requests. The reason I mentioned this was because the actual syscall pattern per request might not require 1 io_submit(2)/io_getevents(2) if you are processing a lot of requests in parallel. The only way to know why kvmtool is slower is by profiling... Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
