[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular |
Date: |
Thu, 05 Dec 2013 10:40:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
Il 05/12/2013 09:40, Matthias Brugger ha scritto:
> CFQ the state of the art I/O scheduler
The deadline scheduler typically provides much better performance for
server usage (including hosting VMs). It doesn't support some features
such as I/O throttling via cgroups, but QEMU now has a very good
throttling mechanism implemented by Benoit Canet.
I suggest that you repeat your experiments using all six configurations:
- deadline scheduler with aio=native
- deadline scheduler with aio=threads
- deadline scheduler with aio=threads + your patches
- CFQ scheduler with aio=native
- CFQ scheduler with aio=threads
- CFQ scheduler with aio=threads + your patches
> In former versions, there was some work done to merge requests in
> Qemu, but I don't think they were very useful, because you don't know
> how the layout of the image file looks like on the physical disk.
> Anyway I think this code parts have been removed.
This is still there for writes, in bdrv_aio_multiwrite. Only
virtio-blk.c uses it, but it's there.
> The only layer where you really know how the blocks of the virtual
> disk image are distributed over the disk is the block layer of the
> host. So you have to do the block request merging there. With the new
> architecture this would come for free, as you can map every thread
> from a guest to one workerthread of Qemu.
This also assumes a relatively "dumb" guest. If the guest uses itself a
thread pool, you would have exactly the same problem, wouldn't you?
Paolo