qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/6] RFH: We lost "connect" events
Date: Mon, 19 Aug 2019 11:49:16 +0100	[thread overview]
Message-ID: <20190819104916.GG12960@redhat.com> (raw)
In-Reply-To: <87pnl1301v.fsf@trasno.org>

On Mon, Aug 19, 2019 at 12:46:20PM +0200, Juan Quintela wrote:
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Wed, Aug 14, 2019 at 04:02:18AM +0200, Juan Quintela wrote:
> >> When we have lots of channels, sometimes multifd migration fails
> >> with the following error:
> >> 
> >> Any good ideas?
> >
> > In inet_listen_saddr() we call
> >
> >     if (!listen(slisten, 1)) {
> >
> > note the second parameter sets the socket backlog, which is the max
> > number of pending socket connections we allow. My guess is that the
> > target QEMU is not accepting incoming connections quickly enough and
> > thus you hit the limit & the kernel starts dropping the incoming
> > connections.
> >
> > As a quick test, just hack this code to pass a value of 100 and see
> > if it makes your test reliable. If it does, then we'll need to figure
> > out a nice way to handle backlog instead of hardcoding it at 1.
> 
> Nice.
> 
> With this change I can create 100 channels on a 4 core machine without
> any trouble.
> 
> How can we proceed from here?

I don't think we want to expose this in the QAPI schema for the socket
address, since the correct value is really something that QEMU should
figure out based on usage context.

Thus, I think we'll have to make it an explicit parameter to the
qio_channel_socket_listen_{sync,async} APIs, and socket_listen()
and inet_listen_saddr(), etc. Then the migration code can pass in
a sensible value based on multifd usage.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  reply	other threads:[~2019-08-19 10:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14  2:02 [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels Juan Quintela
2019-08-14  2:02 ` [Qemu-devel] [PATCH 1/6] migration: Add traces for multifd terminate threads Juan Quintela
2019-08-14 11:17   ` Dr. David Alan Gilbert
2019-08-19 11:14   ` Philippe Mathieu-Daudé
2019-08-14  2:02 ` [Qemu-devel] [PATCH 2/6] migration: Make global sem_sync semaphore by channel Juan Quintela
2019-08-14 14:34   ` Dr. David Alan Gilbert
2019-08-14  2:02 ` [Qemu-devel] [PATCH 3/6] migration: Make sure that all multifd channels have been created Juan Quintela
2019-08-14 14:58   ` Dr. David Alan Gilbert
2019-08-19  8:29     ` Juan Quintela
2019-08-14  2:02 ` [Qemu-devel] [PATCH 4/6] migration: Make multifd threads wait until all " Juan Quintela
2019-08-14  2:02 ` [Qemu-devel] [PATCH 5/6] migration: add some multifd traces Juan Quintela
2019-08-14 16:23   ` Dr. David Alan Gilbert
2019-08-19 11:10   ` Philippe Mathieu-Daudé
2019-08-19 11:13     ` Philippe Mathieu-Daudé
2019-08-14  2:02 ` [Qemu-devel] [PATCH 6/6] RFH: We lost "connect" events Juan Quintela
2019-08-19  9:52   ` Daniel P. Berrangé
2019-08-19 10:33     ` Juan Quintela
2019-08-19 10:40       ` Daniel P. Berrangé
2019-08-19 10:46     ` Juan Quintela
2019-08-19 10:49       ` Daniel P. Berrangé [this message]
2019-08-19 10:50         ` Juan Quintela
2019-08-19 11:00         ` Peter Maydell
2019-08-19 11:06           ` Daniel P. Berrangé
2019-08-19 10:47     ` Juan Quintela
2019-08-14 11:43 ` [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels no-reply
2019-08-14 14:53 ` Dr. David Alan Gilbert
2019-08-14 23:24 ` no-reply

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=20190819104916.GG12960@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@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).