On Tue, 10 Sep 2019 at 12:26, Dr. David Alan Gilbert
<dgilb...@redhat.com> wrote:
>
> * Beata Michalska (beata.michal...@linaro.org) wrote:
> > Switch to ram block writeback for pmem migration.
> >
> > Signed-off-by: Beata Michalska <beata.michal...@linaro.org>
> > ---
> > migration/ram.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/migration/ram.c b/migration/ram.c
> > index b01a37e7ca..8ea0bd63fc 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -33,7 +33,6 @@
> > #include "qemu/bitops.h"
> > #include "qemu/bitmap.h"
> > #include "qemu/main-loop.h"
> > -#include "qemu/pmem.h"
> > #include "xbzrle.h"
> > #include "ram.h"
> > #include "migration.h"
> > @@ -4064,9 +4063,7 @@ static int ram_load_cleanup(void *opaque)
> > RAMBlock *rb;
> >
> > RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
> > - if (ramblock_is_pmem(rb)) {
> > - pmem_persist(rb->host, rb->used_length);
> > - }
> > + qemu_ram_block_writeback(rb);
>
> ACK for migration
>
> Although I do worry that if you really have pmem hardware, is it better
> to fail the migration if you don't have libpmem available?
According to the PMDG man page, pmem_persist is supposed to be
equivalent for the msync.
It's just more performant. So in case of real pmem hardware it should
be all good.
[http://pmem.io/pmdk/manpages/linux/v1.2/libpmem.3.html]
BR
Beata
>
> Dave
>
> > }
> >
> > xbzrle_load_cleanup();
> > --
> > 2.17.1
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
