All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: den@openvz.org, Denis Plotnikov <dplotnikov@virtuozzo.com>,
	qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [RFC patch v1 2/3] qemu-file: add buffered mode
Date: Mon, 4 May 2020 10:08:55 +0100	[thread overview]
Message-ID: <20200504090855.GA115875@redhat.com> (raw)
In-Reply-To: <20200427121433.GI2923@work-vm>

On Mon, Apr 27, 2020 at 01:14:33PM +0100, Dr. David Alan Gilbert wrote:
> * Denis Plotnikov (dplotnikov@virtuozzo.com) wrote:
> > The patch adds ability to qemu-file to write the data
> > asynchronously to improve the performance on writing.
> > Before, only synchronous writing was supported.
> > 
> > Enabling of the asyncronous mode is managed by new
> > "enabled_buffered" callback.
> 
> It's a bit invasive isn't it - changes a lot of functions in a lot of
> places!
> The multifd code separated the control headers from the data on separate
> fd's - but that doesn't help your case.
> 
> Is there any chance you could do this by using the existing 'save_page'
> hook (that RDMA uses).
> 
> In the cover letter you mention direct qemu_fflush calls - have we got a
> few too many in some palces that you think we can clean out?

When I first introduced the QIOChannel framework, I hoped that we could
largely eliminate QEMUFile as a concept.  Thus I'm a bit suspicious of
the idea of introducing more functionality to QEMUFile, especially as the
notion of buffering I/O is rather generic. Is there scope for having a
QIOChannelBuffered object for doing buffering. Would that provide better
isolation from the migration code and thus be less invasive/complex to
maintain ?


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 :|



  parent reply	other threads:[~2020-05-04  9:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 11:12 [RFC patch v1 0/3] qemu-file writing performance improving Denis Plotnikov
2020-04-13 11:12 ` [RFC patch v1 1/3] qemu-file: introduce current buffer Denis Plotnikov
2020-04-24 17:47   ` Vladimir Sementsov-Ogievskiy
2020-04-24 21:12   ` Eric Blake
2020-04-13 11:12 ` [RFC patch v1 2/3] qemu-file: add buffered mode Denis Plotnikov
2020-04-24 21:25   ` Eric Blake
2020-04-27  8:21     ` Denis Plotnikov
2020-04-25  9:10   ` Vladimir Sementsov-Ogievskiy
2020-04-27  8:19     ` Denis Plotnikov
2020-04-27 11:04       ` Vladimir Sementsov-Ogievskiy
2020-04-27 12:14   ` Dr. David Alan Gilbert
2020-04-28  8:06     ` Denis Plotnikov
2020-04-28 17:54       ` Dr. David Alan Gilbert
2020-04-28 20:25         ` Denis Plotnikov
2020-05-04  9:08     ` Daniel P. Berrangé [this message]
2020-04-13 11:12 ` [RFC patch v1 3/3] migration/savevm: use qemu-file buffered mode for non-cached bdrv Denis Plotnikov
2020-04-13 12:10 ` [RFC patch v1 0/3] qemu-file writing performance improving Denis V. Lunev
2020-04-13 13:51 ` no-reply
2020-04-21  8:13 ` Denis Plotnikov

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=20200504090855.GA115875@redhat.com \
    --to=berrange@redhat.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=dplotnikov@virtuozzo.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 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.