| Message ID | 20230210063630.532185-3-leobras@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1,1/4] migration/multifd: Change multifd_load_cleanup() signature and usage | expand |
Leonardo Bras <leobras@redhat.com> wrote: > Current approach will only join threads that are still running. > > For the threads not joined, resources or private memory are always kept in > the process space and never reclaimed before process end, and this risks > serious memory leaks. > > This should usually not represent a big problem, since multifd migration > is usually just ran at most a few times, and after it succeeds there is > not much to be done before exiting the process. > > Yet still, it should not hurt performance to join all of them. > > Signed-off-by: Leonardo Bras <leobras@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>
On Fri, Feb 10, 2023 at 03:36:30AM -0300, Leonardo Bras wrote: > Current approach will only join threads that are still running. > > For the threads not joined, resources or private memory are always kept in > the process space and never reclaimed before process end, and this risks > serious memory leaks. > > This should usually not represent a big problem, since multifd migration > is usually just ran at most a few times, and after it succeeds there is > not much to be done before exiting the process. > > Yet still, it should not hurt performance to join all of them. > > Signed-off-by: Leonardo Bras <leobras@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
diff --git a/migration/multifd.c b/migration/multifd.c index 1a445b36f1..7e37a459ed 100644 --- a/migration/multifd.c +++ b/migration/multifd.c @@ -1039,8 +1039,9 @@ void multifd_load_cleanup(void) * however try to wakeup it without harm in cleanup phase. */ qemu_sem_post(&p->sem_sync); - qemu_thread_join(&p->thread); } + + qemu_thread_join(&p->thread); } for (i = 0; i < migrate_multifd_channels(); i++) { MultiFDRecvParams *p = &multifd_recv_state->params[i];
Current approach will only join threads that are still running. For the threads not joined, resources or private memory are always kept in the process space and never reclaimed before process end, and this risks serious memory leaks. This should usually not represent a big problem, since multifd migration is usually just ran at most a few times, and after it succeeds there is not much to be done before exiting the process. Yet still, it should not hurt performance to join all of them. Signed-off-by: Leonardo Bras <leobras@redhat.com> --- migration/multifd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)