Peter Xu <pet...@redhat.com> writes: > 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.
Sounds like there's a use case for management applications querying TIDs, but query-migrationthreads falls short of serving it. > 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. True. > 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)? If we decide we want to serve the management application use case now, we should provide a suitable interface, then deprecate query-migrationthreads. If we decide not now or not at all, we can deprecate it right away. Removal without deprecation is also possible, but I doubt breaking our compatibility promise is justified. > I added the author Jiacheng too. Users of query-migrationthreads, please speak up!
