From: Juan Quintela <quintela@redhat.com>
To: Leonardo Bras Soares Passos <leobras@redhat.com>
Cc: "Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
"John G Johnson" <john.g.johnson@oracle.com>,
"Jagannathan Raman" <jag.raman@oracle.com>,
qemu-block@nongnu.org, qemu-devel <qemu-devel@nongnu.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Fam Zheng" <fam@euphon.net>, "Eric Blake" <eblake@redhat.com>
Subject: Re: [PATCH v8 5/5] multifd: Implement zero copy write in multifd migration (multifd-zero-copy)
Date: Fri, 18 Feb 2022 18:36:03 +0100 [thread overview]
Message-ID: <87v8xcaxh8.fsf@secure.mitica> (raw)
In-Reply-To: <CAJ6HWG44WaWmCopWvF6-vbzMg8A-QWV85Vv2VmgEA7cs4CfM3Q@mail.gmail.com> (Leonardo Bras Soares Passos's message of "Mon, 7 Feb 2022 23:49:38 -0300")
Leonardo Bras Soares Passos <leobras@redhat.com> wrote:
> Hello Peter, thanks for reviewing!
>
> On Mon, Feb 7, 2022 at 11:22 PM Peter Xu <peterx@redhat.com> wrote:
>>
>> On Tue, Feb 01, 2022 at 03:29:03AM -0300, Leonardo Bras wrote:
>> > -void multifd_send_sync_main(QEMUFile *f)
>> > +int multifd_send_sync_main(QEMUFile *f)
>> > {
>> > int i;
>> > + bool flush_zero_copy;
>> >
>> > if (!migrate_use_multifd()) {
>> > - return;
>> > + return 0;
>> > }
>> > if (multifd_send_state->pages->num) {
>> > if (multifd_send_pages(f) < 0) {
>> > error_report("%s: multifd_send_pages fail", __func__);
>> > - return;
>> > + return 0;
>>
>> I've not checked how it used to do if multifd_send_pages() failed, but.. should
>> it returns -1 rather than 0 when there will be a return code?
>
> Yeah, that makes sense.
> The point here is that I was trying not to modify much of the current behavior.
if (qatomic_read(&multifd_send_state->exiting)) {
return -1;
}
if (p->quit) {
error_report("%s: channel %d has already quit!", __func__, i);
qemu_mutex_unlock(&p->mutex);
return -1;
}
This are the only two cases where the current code can return one
error. In the 1st case we are exiting, we are already in the middle of
finishing, so we don't really care.
In the second one, we have already quit, and error as already quite big.
But I agree with both comments:
- we need to improve the error paths
- leonardo changes don't affect what is already there.
> I mean, multifd_send_sync_main() would previously return void, so any
> other errors would not matter to the caller of this function, which
> will continue to run as if nothing happened.
>
> Now, if it fails with flush_zero_copy, the operation needs to be aborted.
>
> Maybe, I should make it different:
> - In any error, return -1.
> - Create/use a specific error code in the case of a failing
> flush_zero_copy, so I can test the return value for it on the caller
> function and return early.
We need to add the check. It don't matter if the problem is zero_copy
or the existing one, we are under a minor catastrophe and migration has
to be aborted.
> Or alternatively, the other errors could also return early, but since
> this will change how the code currently works, I would probably need
> another patch for that change. (so it can be easily reverted if
> needed)
>
> What do you think is better?
>
>
>> > }
>> > }
>> > +
>> > + /*
>> > + * When using zero-copy, it's necessary to flush after each iteration to
>> > + * make sure pages from earlier iterations don't end up replacing newer
>> > + * pages.
>> > + */
>> > + flush_zero_copy = migrate_use_zero_copy_send();
>> > +
>> > for (i = 0; i < migrate_multifd_channels(); i++) {
>> > MultiFDSendParams *p = &multifd_send_state->params[i];
>> >
>> > @@ -591,7 +600,7 @@ void multifd_send_sync_main(QEMUFile *f)
>> > if (p->quit) {
>> > error_report("%s: channel %d has already quit", __func__, i);
>> > qemu_mutex_unlock(&p->mutex);
>> > - return;
>> > + return 0;
>>
>> Same question here.
>
> Please see above,
>
>>
>> > }
>>
>> The rest looks good. Thanks,
Later, Juan.
next prev parent reply other threads:[~2022-02-18 17:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 6:28 [PATCH v8 0/5] MSG_ZEROCOPY + multifd Leonardo Bras
2022-02-01 6:28 ` [PATCH v8 1/5] QIOChannel: Add flags on io_writev and introduce io_flush callback Leonardo Bras
2022-02-01 9:35 ` Daniel P. Berrangé
2022-02-01 17:25 ` Leonardo Bras Soares Passos
2022-02-07 12:49 ` Peter Xu
2022-02-07 20:50 ` Leonardo Bras Soares Passos
2022-02-18 16:36 ` Juan Quintela
2022-02-21 16:41 ` Leonardo Bras Soares Passos
2022-02-01 6:29 ` [PATCH v8 2/5] QIOChannelSocket: Implement io_writev zero copy flag & io_flush for CONFIG_LINUX Leonardo Bras
2022-02-18 16:38 ` Juan Quintela
2022-02-01 6:29 ` [PATCH v8 3/5] migration: Add zero-copy-send parameter for QMP/HMP for Linux Leonardo Bras
2022-02-18 16:39 ` Juan Quintela
2022-02-01 6:29 ` [PATCH v8 4/5] migration: Add migrate_use_tls() helper Leonardo Bras
2022-02-01 6:29 ` [PATCH v8 5/5] multifd: Implement zero copy write in multifd migration (multifd-zero-copy) Leonardo Bras
2022-02-08 2:22 ` Peter Xu
2022-02-08 2:49 ` Leonardo Bras Soares Passos
2022-02-08 3:05 ` Peter Xu
2022-02-18 17:36 ` Juan Quintela [this message]
2022-02-21 19:47 ` Leonardo Bras Soares Passos
2022-02-18 16:57 ` Juan Quintela
2022-02-21 19:41 ` Leonardo Bras Soares Passos
2022-02-22 4:09 ` Leonardo Bras Soares Passos
2022-03-01 3:57 ` Peter Xu
2022-03-07 14:20 ` 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=87v8xcaxh8.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=elena.ufimtseva@oracle.com \
--cc=fam@euphon.net \
--cc=jag.raman@oracle.com \
--cc=john.g.johnson@oracle.com \
--cc=leobras@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).