Kevin Wolf <kw...@redhat.com> writes: > Am 12.05.2023 um 20:01 hat Fabiano Rosas geschrieben: >> Is there a way to execute a long-standing QMP command outside of the >> BQL? >> >> The situation we're seeing is a slow query-block due to a slow system >> call (fstat over NFS) causing the main thread to spend too long >> holding the global mutex and locking up the vcpu thread when it goes >> out of the guest for MMIO. >> >> The call chain for QMP is: >> >> qmp_query_block >> bdrv_query_info >> bdrv_block_device_info >> bdrv_query_image_info >> bdrv_do_query_node_info >> bdrv_get_allocated_file_size >> bdrv_poll_co <- Waiting with qemu_global_mutex locked >> >> [coroutine] bdrv_co_get_allocated_file_size_entry >> bdrv_co_get_allocated_file_size >> raw_co_get_allocated_file_size >> fstat <- SLOW! > > The first part of the right solution there should be moving fstat() to a > worker thread like we do for other requests where we care about not > blocking. See existing raw_thread_pool_submit() callers for examples. > > Note that this isn't the full solution yet. QMP still has to wait for > bdrv_get_allocated_file_size() to return. bdrv_poll_co() runs a nested > event loop, but it doesn't unlock the BQL. > > So the second part would be converting the block-block QMP handler to > a coroutine so that it can actually yield to the main loop, which will > then drop the BQL while waiting. We would have to be careful there to > make sure that we don't break anything because the sets of things > allowed inside and outside coroutines are different. > > Kevin
Hi Kevin, Thank you, this is what I was looking for. I was missing the raw_thread_pool_submit right there under my nose! I'll put together an RFC so we can discuss the details.
