qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Patch v2] Don't sync volatile memory
@ 2025-06-16 20:56 Chaney, Ben
  2025-06-16 21:18 ` Peter Xu
  0 siblings, 1 reply; 2+ messages in thread
From: Chaney, Ben @ 2025-06-16 20:56 UTC (permalink / raw)
  To: Peter Xu
  Cc: David Hildenbrand, Michael S. Tsirkin, yury-kotov@yandex-team.ru,
	dgilbert@redhat.com, beata.michalska@linaro.org,
	richard.henderson@linaro.org, alex.bennee@linaro.org,
	peter.maydell@linaro.org, junyan.he@intel.com,
	imammedo@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com,
	philmd@linaro.org, xiaoguangrong.eric@gmail.com, Tottenham, Max,
	Hunt, Joshua, Glasgall, Anna, qemu-stable@nongnu.org

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 <bchaney@akamai.com>
Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)
---
migration/ram.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index d26dbd37c4..e857b579d6 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3672,7 +3672,9 @@ static int ram_load_cleanup(void *opaque)
     RAMBlock *rb;

     RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
-        qemu_ram_block_writeback(rb);
+        if (memory_region_is_nonvolatile(rb->mr)) {
+            qemu_ram_block_writeback(rb);
+        }
     }

     xbzrle_load_cleanup();
--
2.40.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [Patch v2] Don't sync volatile memory
  2025-06-16 20:56 [Patch v2] Don't sync volatile memory Chaney, Ben
@ 2025-06-16 21:18 ` Peter Xu
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Xu @ 2025-06-16 21:18 UTC (permalink / raw)
  To: Chaney, Ben
  Cc: David Hildenbrand, Michael S. Tsirkin, yury-kotov@yandex-team.ru,
	dgilbert@redhat.com, beata.michalska@linaro.org,
	richard.henderson@linaro.org, alex.bennee@linaro.org,
	peter.maydell@linaro.org, junyan.he@intel.com,
	imammedo@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com,
	philmd@linaro.org, xiaoguangrong.eric@gmail.com, Tottenham, Max,
	Hunt, Joshua, Glasgall, Anna, qemu-stable@nongnu.org

On Mon, Jun 16, 2025 at 08:56:50PM +0000, Chaney, Ben wrote:
> 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 <bchaney@akamai.com>
> Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)

I've queued it with an update on the subject and commit message, as
following:

    migration: Don't sync volatile memory after migration completes
    
    Syncing volatile memory provides no benefit, instead it can cause
    performance issues in some cases.  Only sync memory that is marked as
    non-volatile after migration completes on destination.

Thanks,

> ---
> migration/ram.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index d26dbd37c4..e857b579d6 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3672,7 +3672,9 @@ static int ram_load_cleanup(void *opaque)
>      RAMBlock *rb;
> 
>      RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
> -        qemu_ram_block_writeback(rb);
> +        if (memory_region_is_nonvolatile(rb->mr)) {
> +            qemu_ram_block_writeback(rb);
> +        }
>      }
> 
>      xbzrle_load_cleanup();
> --
> 2.40.1
> 

-- 
Peter Xu



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-06-16 21:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-16 20:56 [Patch v2] Don't sync volatile memory Chaney, Ben
2025-06-16 21:18 ` Peter Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).