All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-devel@nongnu.org,  jasowang@redhat.com,  philmd@linaro.org,
	thuth@redhat.com,  berrange@redhat.com,
	 marcandre.lureau@redhat.com, pbonzini@redhat.com,
	 leobras@redhat.com,  peterx@redhat.com,
	zhanghailiang@xfusion.com,  chen.zhang@intel.com,
	 lukasstraub2@web.de
Subject: Re: [PATCH v5 3/3] migration: process_incoming_migration_co(): move colo part to colo
Date: Mon, 15 May 2023 16:52:26 +0200	[thread overview]
Message-ID: <87r0rhy7dh.fsf@secure.mitica> (raw)
In-Reply-To: <20230515130640.46035-4-vsementsov@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Mon, 15 May 2023 16:06:40 +0300")

Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> wrote:
> Let's make better public interface for COLO: instead of
> colo_process_incoming_thread and not trivial logic around creating the
> thread let's make simple colo_incoming_co(), hiding implementation from
> generic code.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Independent of this patch, I still wonder if moving incoming migration
from a coroutine to a thread makes sense.  On one hand:

- it would simplify (a bit) the already complex code
- it would make a bit better in non-multifd migrations, right now, if we
  put enough networking, the botleneck is the migration incoming
  coroutine.

On the other hand:
- We would have to work with bottom handlers (as the outgoing migration
  does)
- With multifd enabled, the amount of data that is sent through the
  main migration channel is just a few MB, so not that it is going to
  improve a lot.

So, it is not clear to me what to do here.

Later, Juan.



  reply	other threads:[~2023-05-15 14:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 13:06 [PATCH v5 0/3] COLO: improve build options Vladimir Sementsov-Ogievskiy
2023-05-15 13:06 ` [PATCH v5 1/3] configure: add --disable-colo-proxy option Vladimir Sementsov-Ogievskiy
2023-05-15 13:06 ` [PATCH v5 2/3] migration: split migration_incoming_co Vladimir Sementsov-Ogievskiy
2023-05-15 13:57   ` Juan Quintela
2023-05-15 13:06 ` [PATCH v5 3/3] migration: process_incoming_migration_co(): move colo part to colo Vladimir Sementsov-Ogievskiy
2023-05-15 14:52   ` Juan Quintela [this message]
2023-05-15 14:55 ` [PATCH v5 0/3] COLO: improve build options Juan Quintela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0rhy7dh.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=berrange@redhat.com \
    --cc=chen.zhang@intel.com \
    --cc=jasowang@redhat.com \
    --cc=leobras@redhat.com \
    --cc=lukasstraub2@web.de \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=vsementsov@yandex-team.ru \
    --cc=zhanghailiang@xfusion.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.