Re: [PATCH 0/7] migration: query-migrationthreads enhancements and cleanups

[Peter Xu <peterx@redhat.com>]

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