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
