qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qcow2 performance plan


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




reply via email to

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