Re: [PATCH v2 15/29] migration/ram: Add support for 'fixed-ram' outgoing migration

[Peter Xu <peterx@redhat.com>]

On Wed, Oct 25, 2023 at 10:39:58AM +0100, Daniel P. Berrangé wrote:
> If I'm reading the code correctly the new format has some padding
> such that each "ramblock pages" region starts on a 1 MB boundary.
> 
> eg so we get:
> 
>  --------------------------------
>  | ramblock 1 header            |
>  --------------------------------
>  | ramblock 1 fixed-ram header  |
>  --------------------------------
>  | padding to next 1MB boundary |
>  | ...                          |
>  --------------------------------
>  | ramblock 1 pages             |
>  | ...                          |
>  --------------------------------
>  | ramblock 2 header            |
>  --------------------------------
>  | ramblock 2 fixed-ram header  |
>  --------------------------------
>  | padding to next 1MB boundary |
>  | ...                          |
>  --------------------------------
>  | ramblock 2 pages             |
>  | ...                          |
>  --------------------------------
>  | ...                          |
>  --------------------------------
>  | RAM_SAVE_FLAG_EOS            |
>  --------------------------------
>  | ...                          |
>  -------------------------------

When reading the series, I was thinking one more thing on whether fixed-ram
would like to leverage compression in the future?

To be exact, not really fixed-ram as a feature, but non-live snapshot as
the real use case.  More below.

I just noticed that compression can be a great feature to have for such use
case, where the image size can be further shrinked noticeably.  In this
case, speed of savevm may not matter as much as image size (as compression
can take some more cpu overhead): VM will be stopped anyway.

With current fixed-ram layout, we probably can't have compression due to
two reasons:

  - We offset each page with page alignment in the final image, and that's
    where fixed-ram as the term comes from; more fundamentally,

  - We allow src VM to run (dropping auto-pause as the plan, even if we
    plan to guarantee it not run; QEMU still can't take that as
    guaranteed), then we need page granule on storing pages, and then it's
    hard to know the size of each page after compressed.

If with the guarantee that VM is stopped, I think compression should be
easy to get?  Because right after dropping the page-granule requirement, we
can compress in chunks, storing binary in the image, one page written once.
We may lose O_DIRECT but we can consider the hardware accelerators on
[de]compress if necessary.

I'm just raising this up to discuss to make sure we're on the same page.
Again, maybe that's not a concern to anyone, but I want to double check
with all of us, because it will affect the whole design including the image
layout.  I want to make sure we don't introduce another totally different
image layout in the near future just to support compression.

Thanks,

-- 
Peter Xu