Hello Peter and Michael, I have a few updates on this:
On Mon, 2023-07-03 at 02:20 -0300, Leonardo Brás wrote:
> Hello Peter and Michael, thanks for reviewing!
>
>
> On Thu, 2023-06-29 at 16:56 -0400, Peter Xu wrote:
> > On Thu, Jun 29, 2023 at 04:06:53PM -0400, Michae
Hello Peter and Michael, thanks for reviewing!
On Thu, 2023-06-29 at 16:56 -0400, Peter Xu wrote:
> On Thu, Jun 29, 2023 at 04:06:53PM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 29, 2023 at 04:01:41PM -0400, Peter Xu wrote:
> > > On Thu, Jun 29, 2023 at 03:33:06PM -0400, Michael S. Tsirkin
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> In the past, we had to put the in the main thread all the operations
> related with sizes due to qemu_file not beeing thread safe. As now
> all counters are atomic, we can update the counters just after the
> do the write. As an aditional
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> When we sent a page through QEMUFile hooks (RDMA) there are three
> posiblities:
> - We are not using RDMA. return RAM_SAVE_CONTROL_DELAYED and
> control_save_page() returns false to let anything else to proceed.
> - There is one error
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> After this change, nothing abuses QEMUFile to account for data
> transferrefd during migration.
>
> Signed-off-by: Juan Quintela
> ---
> migration/qemu-file.h | 8
> migration/qemu-file.c | 5 -
> 2 files changed, 13
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> RDMA protocol is completely asynchronous, so in qemu_rdma_save_page()
> they "invent" that a byte has been transferred. And then they call
> qemu_file_credit_transfer() and ram_transferred_add() with that byte.
> Just remove that calls as
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> ---
> migration/rdma.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 074456f9df..416dec00a2 100644
> ---
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Remove the one in control_save_page().
>
> Signed-off-by: Juan Quintela
> ---
> migration/ram.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index a706edecc0..67ed49b387 100644
> ---
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Just create a variable for it, the same way that multifd does. This
> way it is safe to use for other thread, etc, etc.
>
> Signed-off-by: Juan Quintela
> ---
> migration/migration-stats.h | 4
> migration/migration-stats.c | 5
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Since previous commit, we calculate how much data we have send with
> migration_transferred_bytes() so no need to maintain this counter and
> remember to always update it.
>
> Signed-off-by: Juan Quintela
> Reviewed-by: Cédric Le Goater
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> Reviewed-by: Cédric Le Goater
> ---
> migration/migration-stats.h | 8 +++-
> migration/migration-stats.c | 7 +--
> migration/migration.c | 2 +-
> 3 files changed, 13 insertions(+), 4
On Mon, 2023-05-15 at 21:57 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> Reviewed-by: Cédric Le Goater
> ---
> migration/migration-stats.c | 8 ++--
> migration/trace-events | 3 +++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> Once there rename it to migration_transferred_bytes() and pass a
> QEMUFile instead of a migration object.
>
> Signed-off-by: Juan Quintela
> Reviewed-by: Cédric Le Goater
> ---
> migration/migration-stats.h | 11 +++
>
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> These way we can make them atomic and use this functions from any
> place. I also moved all functions that use rate_limit to
> migration-stats.
>
> Functions got renamed, they are not qemu_file anymore.
>
> qemu_file_rate_limit ->
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> That is the moment we know we have transferred something.
>
> Signed-off-by: Juan Quintela
> Reviewed-by: Cédric Le Goater
> ---
> migration/qemu-file.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> It is a time that needs to be cleaned each time cancel migration.
> Once there create migration_time_since() to calculate how time since a
> time in the past.
>
> Signed-off-by: Juan Quintela
>
> ---
>
> Rename to migration_time_since
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> We forget several places to add to trasferred amount of data. With
> this fixes I get:
>
>qemu_file_transferred() + multifd_bytes == transferred
>
> The only place whrer this is not true is during devices sending. But
> going all
On Tue, 2023-05-16 at 14:47 +0200, Cédric Le Goater wrote:
> On 5/16/23 11:24, Juan Quintela wrote:
> > David Edmondson wrote:
> > > Juan Quintela writes:
> > >
> > > > Define and use RATE_LIMIT_MAX instead.
> > >
> > > Suggest "RATE_LIMIT_MAX_NONE".
> >
> > Then even better
> >
> >
Hello Michael, Juan, Peter,
On Wed, 2023-04-26 at 09:19 +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Apr 25, 2023 at 08:42:17PM -0400, Peter Xu wrote:
> > > Hi, Michael, Jonathan,
> > >
> > > On Tue, Mar 07, 2023 at 08:13:53PM -0500, Michael S. Tsirkin wrote:
> > > This
On Thu, 2023-03-30 at 18:18 -0400, Peter Xu wrote:
> On Thu, Mar 30, 2023 at 04:59:09PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Thu, Mar 30, 2023 at 10:36:11AM -0400, Peter Xu wrote:
> > > > On Thu, Mar 30, 2023 at 03:20:14PM +0100,
On Fri, 2023-02-10 at 03:36 -0300, Leonardo Bras wrote:
> Currently running migration_incoming_state_destroy() without first running
> multifd_load_cleanup() will cause a yank error:
>
> qemu-system-x86_64: ../util/yank.c:107: yank_unregister_instance:
> Assertion `QLIST_EMPTY(>yankfns)' failed.
Sent with the incorrect credentials. Sorry about the noise.
Will resend them correctly.
On Fri, 2023-02-10 at 03:31 -0300, Leonardo Bras wrote:
> Since it's introduction in commit f986c3d256 ("migration: Create multifd
> migration threads"), multifd_load_cleanup() never returned any value
>
On Tue, 2022-11-29 at 15:50 -0500, Peter Xu wrote:
> On Tue, Nov 29, 2022 at 05:28:26PM -0300, Leonardo Bras Soares Passos wrote:
> > Hello Peter,
>
> Leo,
>
> >
> > On Thu, Nov 24, 2022 at 1:04 PM Peter Xu wrote:
> > >
> > > On Wed, Nov 09, 2022 at 02:56:29AM -0300, Leonardo Bras wrote:
> >
On Tue, 2022-10-25 at 12:07 +0200, Juan Quintela wrote:
> Daniel P. Berrangé wrote:
> > On Tue, Oct 25, 2022 at 01:47:31AM -0300, Leonardo Bras wrote:
> > > Zero-copy multifd migration sends both the header and the memory pages in
> > > a
> > > single syscall. Since it's necessary to flush
On Tue, 2022-10-25 at 11:51 +0200, Juan Quintela wrote:
> Leonardo Bras wrote:
> > When zero-copy-send is enabled, each loop iteration of the
> > multifd_send_thread will calls for qio_channel_write_*() twice: The first
> > one for sending the header without zero-copy flag and the second one for
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> This implements the zero page dection and handling.
>
> Signed-off-by: Juan Quintela
>
> ---
>
> Add comment for offset (dave)
> Use local variables for offset/block to have shorter lines
> ---
> migration/multifd.h | 5 +
>
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> This patch adds counters and similar. Logic will be added on the
> following patch.
>
> Signed-off-by: Juan Quintela
>
> ---
>
> Added counters for duplicated/non duplicated pages.
> Removed reviewed by from David.
> Add
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
>
> ---
>
> - Check zero_page property before using new code (Dave)
> ---
> migration/migration.c | 4 +---
> migration/multifd.c | 6 +++---
> migration/ram.c | 33
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> ---
> migration/ram.h | 1 +
> migration/ram.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/migration/ram.h b/migration/ram.h
> index e844966f69..038d52f49f 100644
> ---
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> We have to enable it by default until we introduce the new code.
>
> Signed-off-by: Juan Quintela
>
> ---
>
> Change it to a capability. As capabilities are off by default, have
> to change MULTIFD_ZERO_PAGE to MAIN_ZERO_PAGE, so it is
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> We do the send_prepare() and the fill of the head packet without the
> mutex held. It will help a lot for compression and later in the
> series for zero pages.
>
> Notice that we can use p->pages without holding p->mutex because
>
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> Use of flags with respect to locking was incensistant. For the
> sending side:
> - it was set to 0 with mutex held on the multifd channel.
> - MULTIFD_FLAG_SYNC was set with mutex held on the migration thread.
> - Everything else was done
On Tue, 2022-08-02 at 08:38 +0200, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> Reviewed-by: Dr. David Alan Gilbert
> Reviewed-by: David Edmondson
> Signed-off-by: Juan Quintela
Is this doubled Signed-off-by intentional?
> ---
> migration/ram.h | 2 ++
> migration/ram.c | 2 +-
> 2
Hello Juan,
On Tue, 2022-08-02 at 08:38 +0200, Juan Quintela wrote:
> We were calling qemu_target_page_size() left and right.
>
> Signed-off-by: Juan Quintela
IMHO looks a good idea to bring that info inside the multifd parameters.
> ---
> migration/multifd.h | 4
>
On Tue, 2022-08-02 at 08:39 +0200, Juan Quintela wrote:
> We are going to create a new function for multifd latest in the series.
>
> Signed-off-by: Juan Quintela
> Reviewed-by: Dr. David Alan Gilbert
> Signed-off-by: Juan Quintela
Double Signed-off-by again.
> ---
> migration/ram.c | 13
On Tue, 2022-08-02 at 08:38 +0200, Juan Quintela wrote:
> Current code asumes that all pages are whole. That is not true for
> example for compression already. Fix it for creating a new field
> ->sent_bytes that includes it.
>
> All ram_counters are used only from the migration thread, so we
On Tue, 2022-08-02 at 08:38 +0200, Juan Quintela wrote:
> We were recalculating it left and right. We plan to change that
> values on next patches.
>
> Signed-off-by: Juan Quintela
> ---
> migration/multifd.h | 4
> migration/multifd.c | 7 ---
> 2 files changed, 8 insertions(+), 3
On Thu, 2022-07-07 at 16:06 -0400, Peter Xu wrote:
> On Thu, Jul 07, 2022 at 04:59:22PM -0300, Leonardo Bras Soares Passos wrote:
> > Hello Peter,
> >
> > On Thu, Jul 7, 2022 at 2:56 PM Peter Xu wrote:
> > >
> > > On Mon, Jul 04, 2022 at 05:23:15PM -0300, Leonardo Bras wrote:
> > > > Some
On Thu, 2022-07-07 at 15:56 -0400, Peter Xu wrote:
> On Thu, Jul 07, 2022 at 04:50:47PM -0300, Leonardo Bras Soares Passos wrote:
> > > I also think we should squash
> > > patch 2/3 as patch 3 only started to provide meaningful values.
> >
> > IIRC Previously in zero-copy-send implementation, I
On Thu, 2022-07-07 at 15:52 -0400, Peter Xu wrote:
> On Thu, Jul 07, 2022 at 04:44:21PM -0300, Leonardo Bras Soares Passos wrote:
> > Hello Peter,
> >
> > On Thu, Jul 7, 2022 at 2:47 PM Peter Xu wrote:
> > >
> > > Hi, Leo,
> > >
> > > On Mon, Jul 04, 2022 at 05:23:13PM -0300, Leonardo Bras
Thanks Daniel, Markus and Dave for the feedback!
On Mon, 2022-07-04 at 14:14 +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 04, 2022 at 02:59:50PM +0200, Markus Armbruster wrote:
> > Daniel P. Berrangé writes:
> >
> > > On Mon, Jul 04, 2022 at 02:04:41PM +0200, Markus Armbruster wrote:
> >
On Tue, 2022-06-28 at 17:56 +0100, Dr. David Alan Gilbert wrote:
> * Leonardo Bras Soares Passos (leob...@redhat.com) wrote:
> > On Tue, Jun 28, 2022 at 10:52 AM Dr. David Alan Gilbert
> > wrote:
> > >
> > > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > > On Tue, Jun 28, 2022 at
Hello Juan,
On Tue, 2022-06-21 at 16:05 +0200, Juan Quintela wrote:
> We need to add a new flag to mean to sync at that point.
> Notice that we still synchronize at the end of setup and at the end of
> complete stages.
>
> Signed-off-by: Juan Quintela
> ---
> migration/migration.c | 2 +-
>
On Mon, 2022-06-20 at 11:44 -0400, Peter Xu wrote:
> On Mon, Jun 20, 2022 at 11:23:53AM +0200, Juan Quintela wrote:
> > Once discussed this, what I asked in the past is that you are having too
> > much dirty memory on zero_copy. When you have a Multiterabyte guest, in
> > a single round you have
On Mon, 2022-06-20 at 11:23 +0200, Juan Quintela wrote:
> Leonardo Bras wrote:
> > When sending memory pages with MSG_ZEROCOPY, it's necessary to flush
> > to make sure all dirty pages are sent before a future version of them
> > happens to be sent.
> >
> > Currently, the flush happens every
Hello Igor,
On Tue, 2022-02-01 at 09:29 +0100, Igor Mammedov wrote:
> On Mon, 31 Jan 2022 12:53:31 +
> David Edmondson wrote:
>
> > On Saturday, 2022-01-29 at 06:46:45 -03, Leonardo Bras wrote:
> >
> > > The following steps describe a migration bug:
> > > 1 - Bring up a VM with -cpu EPYC
Hello David, thanks for this feedback!
On Mon, 2022-01-31 at 12:53 +, David Edmondson wrote:
> On Saturday, 2022-01-29 at 06:46:45 -03, Leonardo Bras wrote:
>
> > The following steps describe a migration bug:
> > 1 - Bring up a VM with -cpu EPYC on a host with EPYC-Milan cpu
> > 2 - Migrate
On Mon, 2021-06-14 at 07:14 +0200, Philippe Mathieu-Daudé wrote:
> Hi Leonardo,
>
> On 6/9/21 4:45 PM, Dr. David Alan Gilbert (git) wrote:
> > From: Leonardo Bras
> >
> > After yank feature was introduced in migration, whenever migration
> > is started using TLS, the following error happens in
On Tue, 2021-06-01 at 10:50 -0400, Peter Xu wrote:
> On Tue, Jun 01, 2021 at 02:40:31AM -0300, Leonardo Bras wrote:
> > [...]
> > inside migration_channel_connect() and
> > migration_channel_process_incoming() move yank_register_function()
> > so
> > it only runs once on a TLS migration.
>
>
On Tue, 2021-06-01 at 13:00 +0200, Lukas Straub wrote:
> [...]
> Looks good to me,
> Reviewed-by: Lukas Straub
>
Thanks!
CC: Daniel P. Berrange
On Wed, 2021-05-26 at 19:16 -0300, Leonardo Bras wrote:
> After yank feature was introduced, whenever migration is started using
> TLS,
> the following error happens in both source and destination hosts:
>
> (qemu) qemu-kvm: ../util/yank.c:107: yank_unregister_instance:
>
Hello Lukas, thanks for this feedback!
On Wed, 2021-05-26 at 23:24 +0200, Lukas Straub wrote:
> > diff --git a/migration/multifd.c b/migration/multifd.c
> > index 0a4803cfcc..be8656f4c0 100644
> > --- a/migration/multifd.c
> > +++ b/migration/multifd.c
> > @@ -987,8 +987,9 @@ int
52 matches
Mail list logo
