Not all pmem regions are backed by non-volatile memory. Syncing volatile
memory provides no benefit, but can cause performance issues is some
cases. Only sync memory that is marked as non-volatile.
Signed-off-by: Ben Chaney
Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)
---
m
On 6/16/25, 4:35 PM, "Peter Xu" mailto:pet...@redhat.com>>
wrote:
> On Mon, Jun 16, 2025 at 07:43:02PM +, Chaney, Ben wrote:
>> Not all pmem regions are backed by non-volatile memory. Syncing volatile
>> memory provides no benefit, but can cause performanc
Not all pmem regions are backed by non-volatile memory. Syncing volatile
memory provides no benefit, but can cause performance issues is some
cases. Only sync memory that is marked as non-volatile.
Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)
---
migration/ram.c | 4 +++-
1
On 5/14/25, 9:59 AM, "David Hildenbrand" mailto:da...@redhat.com>> wrote:
>Because we need to make sure the pmem kind memory data is synced
>after migration, we choose to call pmem_persist() when the migration
>finish. This will make sure the data of pmem is safe and will not
>lose if power is o
On 5/13/25, 1:21 PM, "David Hildenbrand" mailto:da...@redhat.com>> wrote:
> Are you using a read-only NVDIMM?
> In that case, I assume we would never need msync.
We aren't using an NVDIMM at all, we are using pmem that is backed by DRAM.
Ben
On 5/12/25, 2:50 PM, "Peter Xu" mailto:pet...@redhat.com>>
wrote:
> What you said makes sense to me, but I'm neither pmem user nor
> expert. Let's wait to see whether others would like to chime in.
> What's the first bad commit of the regression? Is it since v10.0 release?
Hi Peter,
W
Hello,
When live migrating to a destination host with pmem there is a very
long downtime where the guest is paused. In some cases, this can be as high as
5 minutes, compared to less than one second in the good case.
Profiling suggests very high activity in this code path:
fff
Hello,
While testing CPR transfer I encountered two issues. The first is that the
transfer fails when running with pidfiles due to the destination qemu process
attempting to create the pidfile while it is still locked by the source
process. The second is that the transfer fails when running wit
Hello Steve,
Thank you for posting the qemu cpr-transfer patches on qemu-devel. I am
experimenting with them, and I noticed that cpr-transfer is failing on some
qemu machine types. cpr-transfer is working for me on the microvm machine type
but failing on q35 and pc-i440fx. When running in those
