public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Yishai Hadas <yishaih@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"jgg@nvidia.com" <jgg@nvidia.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Martins, Joao" <joao.m.martins@oracle.com>,
	"leonro@nvidia.com" <leonro@nvidia.com>,
	"shayd@nvidia.com" <shayd@nvidia.com>,
	"maorg@nvidia.com" <maorg@nvidia.com>,
	"avihaih@nvidia.com" <avihaih@nvidia.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>
Subject: Re: [PATCH V2 vfio 00/14] Add migration PRE_COPY support for mlx5 driver
Date: Sun, 4 Dec 2022 13:54:44 +0200	[thread overview]
Message-ID: <df08435e-324c-6d53-1cf5-bedea040bb2d@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276C44FA0D38980746EC27A8C179@BN9PR11MB5276.namprd11.prod.outlook.com>

On 02/12/2022 10:57, Tian, Kevin wrote:
>> From: Yishai Hadas <yishaih@nvidia.com>
>> Sent: Thursday, December 1, 2022 11:29 PM
>>
>> In mlx5 driver we could gain with this series about 20-30 percent
>> improvement
>> in the downtime compared to the previous code when PRE_COPY wasn't
>> supported.
>>
> Curious to see more data here.
>
> what is the workload/configuration?
We tested with multiple workloads which were varied by the number of 
allocated resources, number of VFs on the VM, busy or idle device 
depending on some traffic that runs in the background, etc.
>
> What is the size of the full state and downtime w/o PRECOPY?

It depends on the amount of the allocated resources that were already 
opened upon the migration, and the other workloads parameters as 
mentioned above.

The downtime gain was mainly achieved by sending the initial/middle 
states having the metadata without regard to the size.

>
> with PRECOPY what is the size of initial/middle/final states?

Generally saying, the initial state may include metadata on the current 
state, the middle states may hold 'diff' compared to the 
initial/previous ones and in most cases may be smaller, the final state 
holds the data itself and may be larger.

Yishai


      reply	other threads:[~2022-12-04 11:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 15:29 [PATCH V2 vfio 00/14] Add migration PRE_COPY support for mlx5 driver Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 01/14] net/mlx5: Introduce ifc bits for pre_copy Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 02/14] vfio: Extend the device migration protocol with PRE_COPY Yishai Hadas
2022-12-01 22:43   ` Alex Williamson
2022-12-04  7:38     ` Leon Romanovsky
2022-12-02  8:48   ` Tian, Kevin
2022-12-04  8:35     ` Yishai Hadas
2022-12-02  9:38   ` Shameerali Kolothum Thodi
2022-12-05 13:54     ` Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 03/14] vfio/mlx5: Enforce a single SAVE command at a time Yishai Hadas
2022-12-02  0:51   ` Jason Gunthorpe
2022-12-04 12:07     ` Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 04/14] vfio/mlx5: Refactor PD usage Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 05/14] vfio/mlx5: Refactor MKEY usage Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 06/14] vfio/mlx5: Refactor migration file state Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 07/14] vfio/mlx5: Refactor to use queue based data chunks Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 08/14] vfio/mlx5: Introduce device transitions of PRE_COPY Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 09/14] vfio/mlx5: Introduce SW headers for migration states Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 10/14] vfio/mlx5: Introduce vfio precopy ioctl implementation Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 11/14] vfio/mlx5: Consider temporary end of stream as part of PRE_COPY Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 12/14] vfio/mlx5: Introduce multiple loads Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 13/14] vfio/mlx5: Fallback to STOP_COPY upon specific PRE_COPY error Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 14/14] vfio/mlx5: Enable MIGRATION_PRE_COPY flag Yishai Hadas
2022-12-02  1:06 ` [PATCH V2 vfio 00/14] Add migration PRE_COPY support for mlx5 driver Jason Gunthorpe
2022-12-02  8:57 ` Tian, Kevin
2022-12-04 11:54   ` Yishai Hadas [this message]

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=df08435e-324c-6d53-1cf5-bedea040bb2d@nvidia.com \
    --to=yishaih@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leonro@nvidia.com \
    --cc=maorg@nvidia.com \
    --cc=shayd@nvidia.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