That's very accurate. Zero page scanning *after* the bulk phase
is not very helpful in general.
Are we proposing to skip is_dup_page() after the bulk phase
has finished?
The testcase I'm using is a "worst-case" stress memory hog command
(apt-get install stress) - but against this does not affect anything until
we assume the bulk phase has already completed.
On 04/11/2013 05:18 AM, Paolo Bonzini wrote:
Il 11/04/2013 09:38, Michael S. Tsirkin ha scritto:
On Wed, Apr 10, 2013 at 06:28:18PM -0400, mrhi...@linux.vnet.ibm.com wrote:
From: "Michael R. Hines" <mrhi...@us.ibm.com>
This allows the user to disable zero page checking during migration
Signed-off-by: Michael R. Hines <mrhi...@us.ibm.com>
IMO this knob is too low level to expose to management.
Why not disable this automatically when migrating with rdma?
Thinking more about it, I'm not sure why it is important to disable it.
As observed earlier:
1) non-zero pages typically have a non-zero word in the first 32 bytes,
as measured by Peter Lieven, so the cost of is_dup_page can be ignored
for non-zero pages.
2) all-zero pages typically change little, so they are rare after the
bulk phase where all memory is sent once to the destination.
Hence, the cost of is_dup_page can be ignored after the bulk phase. In
the bulk phase, checking for zero pages it may be expensive and lower
throughput, sure, but what matters for convergence is throughput and
latency _after_ the bulk phase.
At least this is the theory. mrhines, what testcase were you using? If
it is an idle guest, it is not a realistic one and the decreased
latency/throughput does not really matter.
Paolo
