qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]