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. Paolo
