This values were colected by Peter Xu.  One can see how long it takes to do the is_zero_range()


Idle guest precopy test
(Corresponds to "idle db")
==========================

Summary: Most cpu time consumed on zero page detection.  live_migration eats
100% cpu.  Expected.

+   74.73%     0.07%  qemu-system-x86_64       [.] is_zero_range
+   74.66%     0.18%  qemu-system-x86_64       [.] buffer_is_zero
+   74.46%     0.12%  qemu-system-x86_64       [.] select_accel_fn
+   74.37%    74.23%  qemu-system-x86_64       [.] buffer_zero_avx2
+   51.77%     0.29%  qemu-system-x86_64       [.] ram_save_host_page
+   48.75%     0.23%  qemu-system-x86_64       [.] ram_save_target_page
+   47.60%     0.18%  qemu-system-x86_64       [.] save_zero_page
+   47.42%     0.14%  qemu-system-x86_64       [.] save_zero_page_to_file
+   35.42%     0.00%  qemu-system-x86_64       [.] ram_save_iterate

Have requested Nitesh and Juan to help see this bug, below is the talk through Gchat:
-- I: this bug is close to out of stale, it's an RFE bug, do we have the plan to support it on RHEL 9.3.0?
-- Nitesh: I have requested Juan to update the status once he does that we will extend the stale date


Let's wait for Juan's update.

Hi
So get meassurement this working, I got that our counters are not up to the task.  I started improving the counters upstream, last sent url was:

[PATCH 00/21] Migration: More migration atomic counters
https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg01870.html
Migration: Make more ram_counters atomic (v4)
https://lists.gnu.org/archive/html/qemu-devel/2023-04/msg04210.html
[PATCH v3 00/12] Migration: Make more ram_counters atomic
https://www.mail-archive.com/qemu-devel@nongnu.org/msg955025.html

There has been more in the last three weeks.  After that the zero page detection is only three patches on top of that.

Thanks, Juan.

There is no easy way to check that the counters are better quality.  But there is one that before was completely wrong and that is multifd_bytes when we are using multifd compression.  With the old code it shows as if there is no compression, transferred_bytes = number of pages * page_size (+ some headers sizes), with the new ones it is much smaller (depending of the compression of the pages we are talking about).

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.