On Tue, Oct 01, 2024 at 03:25:14PM +0100, Daniel P. Berrangé wrote: > On Tue, Oct 01, 2024 at 07:46:09AM +0200, Markus Armbruster wrote: > > Command query-migrationthreads went in without a QAPI ACK. Issues > > review should have caught: > > > > * Flawed documentation. Fixed in commit e6c60bf02d1. > > > > * It should have been spelled query-migration-threads. Not worth fixing > > now, I guess. > > > > * What are the use cases? The commit message doesn't tell! If it's > > just for debugging, the command should be marked unstable. > > It is hard to use too. > > Lets say a mgmt app wants to restrict migration threads to some > certain pCPUs. It can't call query-migrationthreads beforehand > as the threads don't exist until migration is started. If it > calls after migration is started, then there's a window where > threads are running on arbitrary pCPUs that QEMU has access > to. There's no synchronization point where threads have been > created & can be queried, but are not yet sending data (and > thus burning CPU time)
Indeed, I suppose tricks needed if to work with such model, e.g., mgmt needs to turn bw=0, start migration, query TIDs, then restore bw. However that still lacks at least the dest multifd threads, as currently it only reports src multifd threads TIDs. I don't see why a serious mgmt would like to pin and care only src threads, not dest threads, which can also eat as much (or even more) pCPU resources. For real debugging purpose, I actually don't see a major value out of it either, because GDB can provide all information that this API wants to provide, and only better with thread stacks if we want. Since I don't see how this can be used right, it didn't get proper QAPI reviews, and further I highly suspect whether this API is consumed by anyone at all.. in any serious way. Shall we remove this API (with/without going through the deprecation process)? I added the author Jiacheng too. Thanks, -- Peter Xu
