[Top][All Lists]

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

Re: [Qemu-block] [PATCH] blk: fix aio context loss on media change

From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH] blk: fix aio context loss on media change
Date: Wed, 15 Mar 2017 15:43:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 15/03/2017 15:30, Kevin Wolf wrote:
> Am 15.03.2017 um 14:39 hat Paolo Bonzini geschrieben:
>> On 15/03/2017 12:03, Kevin Wolf wrote:
>>> But we discussed this earlier, and while I'm not completely sure any
>>> more about the details, I seem to remeber that Paolo said something
>>> along the lines that AioContext is going away anyway and building the
>>> code for proper management would be wasted time.
>> AioContext is going to stay, but everybody will be able to send
>> operations to a BB/BDS from any AioContext.  The BDS AioContext will
>> only matter for network devices, since they have to attach the file
>> descriptor handlers somewhere.  For files it won't matter at all because
>> you can use multiple Linux AIO context or thread pools at the same time.
> Should the iothread option then become a -blockdev option rather than a
> -device one?

Well, both.  The device also needs an I/O thread to attach its ioeventfd
handler.  And it makes sense to use the -device I/O thread if -blockdev
specified none.

>> There should be a policy on which BB sets AioContext on the BDS (e.g.
>> only the device does it), but apart from that, it should not be an issue.
> We don't know which BBs are going to be attached. We don't necessarily
> have a device at all, or we could have two of them.

Wow, can we really have two? :-O

> Though maybe we should try to keep a BDS and its children in the same
> AioContext anyway if that's possible? Will it make a difference?

Everything can make sense---but yes, keeping the whole hierarchy in the
same AioContext makes sense more often.


reply via email to

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