On Wed, Oct 02, 2024 at 07:58:48AM +0200, Markus Armbruster wrote: > 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!
I'll go ahead and remove it. The current plan is I'll skip the deprecation procedure for this one because I don't expect anyone would read the deprecation notification at all... aka, no real user I can ever think of, who only cares about source pinning not dest. I'll pick patch 2 out and send separately, which is still a cleanup without the query-migrationthreads API. We can keep the discussion going in the new patch. Thanks, -- Peter Xu
