qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Leonardo Bras Soares Passos <leobras@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	"Eric Blake" <eblake@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH v5 6/6] multifd: Implement zerocopy write in multifd migration (multifd-zerocopy)
Date: Thu, 9 Dec 2021 05:51:54 -0300	[thread overview]
Message-ID: <CAJ6HWG4hJSDSNR5GcON2z6LA0ykMv6x7BVS0vpR3zcQuCOzW+A@mail.gmail.com> (raw)
In-Reply-To: <87pmr0ulqx.fsf@secure.mitica>

Hello Juan,

On Tue, Nov 16, 2021 at 1:08 PM Juan Quintela <quintela@redhat.com> wrote:
>
> Leonardo Bras <leobras@redhat.com> wrote:
> > Implement zerocopy on nocomp_send_write(), by making use of QIOChannel
> > zerocopy interface.
> >
> > Change multifd_send_sync_main() so it can distinguish each iteration sync from
> > the setup and the completion, so a flush_zerocopy() can be called
> > at the after each iteration in order to make sure all dirty pages are sent
> > before a new iteration is started.
> >
> > Also make it return -1 if flush_zerocopy() fails, in order to cancel
> > the migration process, and avoid resuming the guest in the target host
> > without receiving all current RAM.
> >
> > This will work fine on RAM migration because the RAM pages are not usually freed,
> > and there is no problem on changing the pages content between async_send() and
> > the actual sending of the buffer, because this change will dirty the page and
> > cause it to be re-sent on a next iteration anyway.
> >
> > Given a lot of locked memory may be needed in order to use multid migration
> > with zerocopy enabled, make it optional by creating a new migration parameter
> > "zerocopy" on qapi, so low-privileged users can still perform multifd
> > migrations.
>
> How much memory can a non-root program use by default?
>
>
> >  static void *multifd_send_thread(void *opaque)
> > @@ -853,6 +875,10 @@ static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
> >          goto cleanup;
> >      }
> >
> > +    if (migrate_use_zerocopy()) {
> > +        p->write_flags = QIO_CHANNEL_WRITE_FLAG_ZEROCOPY;
> > +    }
>
> This belongs
>
>
> >      p->c = QIO_CHANNEL(sioc);
> >      qio_channel_set_delay(p->c, false);
> >      p->running = true;
> > @@ -918,6 +944,7 @@ int multifd_save_setup(Error **errp)
> >          p->packet->version = cpu_to_be32(MULTIFD_VERSION);
> >          p->name = g_strdup_printf("multifdsend_%d", i);
> >          p->tls_hostname = g_strdup(s->hostname);
> > +        p->write_flags = 0;
>
> here?
>
> >          socket_send_channel_create(multifd_new_send_channel_async, p);
> >      }
> > diff --git a/migration/socket.c b/migration/socket.c
> > index e26e94aa0c..8e40e0a3fd 100644
> > --- a/migration/socket.c
> > +++ b/migration/socket.c
> > @@ -78,8 +78,13 @@ static void socket_outgoing_migration(QIOTask *task,
> >          trace_migration_socket_outgoing_connected(data->hostname);
> >      }
> >
> > -    if (migrate_use_zerocopy()) {
> > -        error_setg(&err, "Zerocopy not available in migration");
> > +    if (migrate_use_zerocopy() &&
> > +        (!migrate_use_multifd() ||
> > +         !qio_channel_has_feature(sioc, QIO_CHANNEL_FEATURE_WRITE_ZEROCOPY) ||
> > +          migrate_multifd_compression() != MULTIFD_COMPRESSION_NONE ||
> > +          migrate_use_tls())) {
> > +        error_setg(&err,
> > +                   "Zerocopy only available for non-compressed non-TLS multifd migration");
> >      }
> >
> >      migration_channel_connect(data->s, sioc, data->hostname, err);
>
> Do we really want to do this check here?  I think this is really too
> late.
>
> You are not patching migrate_params_check().
>
> I think that the proper way of doing this is something like:
>
>     if (params->zerocopy &&
>         (params->parameters.multifd_compression != MULTIFD_COMPRESSION_NONE ||
>          migrate_use_tls())) {
>            error_setg(&err,
>                      "Zerocopy only available for non-compressed non-TLS multifd migration");
>         return false;
>     }

Don't we also need a check for multifd enabled here?
We could have zerocopy, multifd_compression=none, tls=disabled but it
will not fail if multifd=disabled.

Is this correct?


>
> You have to do the equivalent of multifd_compression and tls enablement,
> to see that zerocopy is not enabled, of course.
>
> I would prefer to check for QIO_CHANNEL_FEATUR_WRITE_ZEROCPY there, but
> I can't see a way of doing that without a qio.
>
> Later, Juan.
>



  parent reply	other threads:[~2021-12-09  8:53 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12  5:10 [PATCH v5 0/6] MSG_ZEROCOPY + multifd Leonardo Bras
2021-11-12  5:10 ` [PATCH v5 1/6] QIOChannel: Add io_writev_zerocopy & io_flush_zerocopy callbacks Leonardo Bras
2021-11-12 10:13   ` Daniel P. Berrangé
2021-11-12 10:26     ` Daniel P. Berrangé
2021-11-22 23:18     ` Leonardo Bras Soares Passos
2021-11-23  9:45       ` Daniel P. Berrangé
2021-12-03  5:24         ` Leonardo Bras Soares Passos
2021-12-03  9:15           ` Daniel P. Berrangé
2021-11-12 10:56   ` Daniel P. Berrangé
2021-11-12  5:10 ` [PATCH v5 2/6] QIOChannelSocket: Add flags parameter for writing Leonardo Bras
2021-11-12 10:15   ` Daniel P. Berrangé
2021-11-23  5:33     ` Leonardo Bras Soares Passos
2021-11-12  5:10 ` [PATCH v5 3/6] QIOChannelSocket: Implement io_writev_zerocopy & io_flush_zerocopy for CONFIG_LINUX Leonardo Bras
2021-11-12 10:54   ` Daniel P. Berrangé
2021-11-23  4:46     ` Leonardo Bras Soares Passos
2021-11-23  9:55       ` Daniel P. Berrangé
2021-12-03  5:42         ` Leonardo Bras Soares Passos
2021-12-03  9:17           ` Daniel P. Berrangé
2021-12-09  8:38             ` Leonardo Bras Soares Passos
2021-12-09  8:49               ` Leonardo Bras Soares Passos
2021-11-12  5:10 ` [PATCH v5 4/6] migration: Add zerocopy parameter for QMP/HMP for Linux Leonardo Bras
2021-11-12 11:04   ` Juan Quintela
2021-11-12 11:08     ` Daniel P. Berrangé
2021-11-12 11:59       ` Markus Armbruster
2021-12-01 19:07         ` Leonardo Bras Soares Passos
2021-11-12 12:01     ` Markus Armbruster
2021-12-02  4:31       ` Leonardo Bras Soares Passos
2021-12-01 18:51     ` Leonardo Bras Soares Passos
2021-11-12 11:05   ` Daniel P. Berrangé
2021-12-01 19:05     ` Leonardo Bras Soares Passos
2021-11-12  5:10 ` [PATCH v5 5/6] migration: Add migrate_use_tls() helper Leonardo Bras
2021-11-12 11:04   ` Juan Quintela
2021-11-30 19:00     ` Leonardo Bras Soares Passos
2021-11-12  5:10 ` [PATCH v5 6/6] multifd: Implement zerocopy write in multifd migration (multifd-zerocopy) Leonardo Bras
2021-11-16 16:08   ` Juan Quintela
2021-11-16 16:17     ` Daniel P. Berrangé
2021-11-16 16:34       ` Juan Quintela
2021-11-16 16:39         ` Daniel P. Berrangé
2021-12-02  6:56           ` Leonardo Bras Soares Passos
2021-11-16 16:34       ` Daniel P. Berrangé
2021-12-02  6:54         ` Leonardo Bras Soares Passos
2021-12-02  6:47     ` Leonardo Bras Soares Passos
2021-12-02 12:10       ` Juan Quintela
2021-12-09  8:51     ` Leonardo Bras Soares Passos [this message]
2021-12-09  9:42       ` Leonardo Bras Soares Passos

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=CAJ6HWG4hJSDSNR5GcON2z6LA0ykMv6x7BVS0vpR3zcQuCOzW+A@mail.gmail.com \
    --to=leobras@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).