Re: [PATCH v2 12/17] migration/multifd: Device state transfer support - send side

[Peter Xu <peterx@redhat.com>]

On Fri, Sep 13, 2024 at 03:26:43PM -0300, Fabiano Rosas wrote:
> The thread-pool approach is being looked at to solve this particular
> problem, but we have also discussed in the past that multifd threads
> themselves should be managed by a thread pool. Will we add this
> requirement to what is being done now? Otherwise, don't we risk having
> an implementation that doesn't serve the rest of multifd? Do we even
> know what the requirements are? Keep in mind that we're already not
> modifying the existing ThreadPool, but planning to write a new one.

Multifd currently has below specialties:

  - Multifd thread has 1:1 mapping with iochannels

  - Multifd thread num should be relevant to target bandwidth (e.g., the
    NIC performance)

While for a generic thread pool:

  - Thread has no correlation to any iochannel, but some async cpu
    intensive workloads during migration (either during switchover, or
    maybe even before that?)

  - Thread number should have no correlation to NIC/bandwidth, a sane start
    could be $(nproc), but maybe not..

I don't remember what I was thinking previously, but now it sounds ok to
keep multifd separate as of now to me, because multifd does service a
slightly different purpose (maximum network throughput) v.s. where we want
a pool of threads doing async tasks (which can be anything).

-- 
Peter Xu