Re: [PATCH] migration: Remove interface query-migrationthreads

[Peter Xu <peterx@redhat.com>]

On Fri, Oct 11, 2024 at 05:47:03PM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > This reverts two commits:
> > 
> > 671326201dac8fe91222ba0045709f04a8ec3af4
> > 1b1f4ab69c41279a45ccd0d3178e83471e6e4ec1
> > 
> > Meanwhile it adds an entry to removed-features.rst for the
> > query-migrationthreads QMP command.
> > 
> > This patch originates from another patchset [1] that wanted to cleanup the
> > interface and add corresponding HMP command, as lots of things are missing
> > in the query report; so far it only reports the main thread and multifd
> > sender threads; all the rest migration threads are not reported, including
> > multifd recv threads.
> > 
> > As pointed out by Dan in the follow up discussions [1], the API is designed
> > in an awkward way where CPU pinning may not cover the whole lifecycle of
> > even the thread being reported.  When asked, we also didn't get chance to
> > hear from the developer who introduced this feature to explain how this API
> > can be properly used.
> 
> One suggestion for replacing it, might be a way for a management interface
> to add threads to a thread-pool, prior to migration; and then have migration
> use threads from that pool rather than creating it's own.

It could work indeed.  Though that may require some pool QMP command to
either specify cpu pinning or making the thread all name-based, so that the
names need to be passed over to migration again with another API, which
might be slightly complicated.

I think if we do want to support this feature seriously, either we bare
with that short window (can still use a hack to make bw=0 prior to that),
or we can add one stage of migration so it SETUPs everything and halt there
just like what -S for QEMU in general, until another command to kick off
the migration process.

I remember CPR had such a discussion, that if we have such a mechanism, CPR
state (which must be sent earlier than migration stream) can be sent during
this SETUP-only peroid too.  Since we don't have that, the latest
CPR-transfer is relying on something else (a HUP event on CPR channel sent
from dest by closing it) to identify that window, so that src will block at
SETUP phase until the HUP event from destination CPR channel arrives,
saying "cpr state is loaded, let's continue the migration process".

Thanks,

-- 
Peter Xu