|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] qcow2 performance plan |
Date: | Tue, 14 Sep 2010 18:30:49 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.3 |
On 09/14/2010 05:25 PM, Anthony Liguori wrote:
The incremental version of this is hard for me to understand. bdrv_read() may be implemented in terms of bdrv_aio_read() + qemu_io_wait() which dispatches bottom halves. This is done through a shared resource so if you allow bdrv_read() to be called in parallel, there's a very real possibility that you'll get corruption of a shared resource.You'd have to first instrument bdrv_read() to be re-entrant by acquiring bs.mutex() in every bdrv_read() caller. You would then need to modify the file protocol so that it could safely be called in parallel.IOW, you've got to make the whole block layer thread safe before you can begin to make qcow2 thread safe.
It does rely on CONFIG_IO_THREAD and qemu_mutex. However, we don't need to make the whole block layer safe, just the syncronous parts (drop qemu_mutex after I/O is issued, rely on the image's mutex for internal synchronization).
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |