Re: [Qemu-devel] [Qemu-block] [PATCH] file-posix: unlock qemu_global_mutex before pread when attach disk
Am 11.06.2019 um 04:53 hat l00284672 geschrieben: > -- Would the "open" hang as well in that case? >The "open" doesn't hang in that case. > > Do you have any better solutions to solve this problem in the case? Yes, but unfortunately it's a lot harder. This is roughly what you'd have to do: 1. Make QMP command handlers async (patches from Marc-André are on the list) 2. Stop using HMP drive_add and instead switch to QMP blockdev-add 3. Move the blockdev-add code into a coroutine 4. Make .bdrv_open a coroutine_fn 5. Move the pread() in file-posix to the thread pool and let the coroutine yield while the request is running Only with all of these pieces in place we'll be able to release the global mutex while we're waiting for the pread() to complete. Kevin
Re: [Qemu-devel] [Qemu-block] [PATCH] file-posix: unlock qemu_global_mutex before pread when attach disk
-- Would the "open" hang as well in that case? The "open" doesn't hang in that case. Do you have any better solutions to solve this problem in the case? On 2019/6/11 0:03, Paolo Bonzini wrote: On 10/06/19 16:51, l00284672 wrote: The pread will hang in attaching disk just when backend storage network disconnection . Would the "open" hang as well in that case? I think the locking range of qemu_global_mutex is too large when do qmp operation. what does the qemu_global_mutex really protect? Basically everything. what is the risk of unlocking qemu_global_mutex in qmp? It's not QMP; it's specifically the code that calls raw_probe_alignment. Paolo . <>
Re: [Qemu-devel] [Qemu-block] [PATCH] file-posix: unlock qemu_global_mutex before pread when attach disk
On 10/06/19 16:51, l00284672 wrote: > The pread will hang in attaching disk just when backend storage network > disconnection . Would the "open" hang as well in that case? > I think the locking range of qemu_global_mutex is too large when do qmp > operation. what > does the qemu_global_mutex really protect? Basically everything. > what is the risk of unlocking qemu_global_mutex in qmp? It's not QMP; it's specifically the code that calls raw_probe_alignment. Paolo
Re: [Qemu-devel] [Qemu-block] [PATCH] file-posix: unlock qemu_global_mutex before pread when attach disk
The pread will hang in attaching disk just when backend storage network disconnection . I think the locking range of qemu_global_mutex is too large when do qmp operation. what does the qemu_global_mutex really protect? what is the risk of unlocking qemu_global_mutex in qmp? On 2019/6/10 21:51, Paolo Bonzini wrote: On 10/06/19 15:34, Zhengui li wrote: when do qmp sush as drive_add, qemu main thread locks the qemu_global_mutex and do pread in raw_probe_alignmen. Pread is a synchronous operation. If backend storage network has a large delay or IO pressure is too large, the pread operation will not return for a long time, which make vcpu thread can't acquire qemu_global_mutex for a long time and make the vcpu thread unable to be scheduled for a long time. So virtual machine cpu soft lockup happened. qemu main thread should not hold qemu_global_mutex for a long time when do qmp that involving IO synchronous operation sush pread , ioctl, etc. So this patch unlock qemu_global_mutex before IO synchronous operation sush pread. These preads are for 512-4096 bytes, can they really last much longer than the "open" that precedes them? If pread of 4K can trigger a soft lockup, things are really screwed up---and it's hard to be sure that all callers of raw_probe_alignment are okay with releasing the global mutex. Paolo . <>
Re: [Qemu-devel] [Qemu-block] [PATCH] file-posix: unlock qemu_global_mutex before pread when attach disk
On 10/06/19 15:34, Zhengui li wrote: > > when do qmp sush as drive_add, qemu main thread locks the > qemu_global_mutex and do pread in raw_probe_alignmen. Pread is a > synchronous operation. If backend storage network has a large delay > or IO pressure is too large, the pread operation will not return for > a long time, which make vcpu thread can't acquire qemu_global_mutex > for a long time and make the vcpu thread unable to be scheduled for a > long time. So virtual machine cpu soft lockup happened. > > qemu main thread should not hold qemu_global_mutex for a long time > when do qmp that involving IO synchronous operation sush pread , > ioctl, etc. So this patch unlock qemu_global_mutex before IO > synchronous operation sush pread. These preads are for 512-4096 bytes, can they really last much longer than the "open" that precedes them? If pread of 4K can trigger a soft lockup, things are really screwed up---and it's hard to be sure that all callers of raw_probe_alignment are okay with releasing the global mutex. Paolo
