From: Tao Su <tao1.su@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, shuah@kernel.org,
yi1.lai@intel.com, David Matlack <dmatlack@google.com>
Subject: Re: [PATCH v2] KVM: selftests: Fix dirty_log_page_splitting_test as page migration
Date: Mon, 29 Jan 2024 16:21:12 +0800 [thread overview]
Message-ID: <Zbdf+GSYU+5EGfBL@linux.bj.intel.com> (raw)
In-Reply-To: <ZbQYlYz5aCPFal5f@google.com>
On Fri, Jan 26, 2024 at 12:39:49PM -0800, Sean Christopherson wrote:
> +David
>
[ ... ]
> >
> > /*
> > @@ -192,7 +193,6 @@ static void run_test(enum vm_guest_mode mode, void *unused)
> > * memory again, the page counts should be the same as they were
> > * right after initial population of memory.
> > */
> > - TEST_ASSERT_EQ(stats_populated.pages_4k, stats_repopulated.pages_4k);
> > TEST_ASSERT_EQ(stats_populated.pages_2m, stats_repopulated.pages_2m);
> > TEST_ASSERT_EQ(stats_populated.pages_1g, stats_repopulated.pages_1g);
>
> Isn't it possible that something other than guest data could be mapped by THP
> hugepage, and that that hugepage could get shattered between the initial run and
> the re-population run?
Good catch, I found that if the backing source is specified as THP, all hugepages
can also be migrated.
>
> The test knows (or at least, darn well should know) exactly how much memory is
> being dirty logged. Rather that rely *only* on before/after heuristics, can't
> we assert that the _delta_, i.e. the number of hugepages that are split, and then
> the number of hugepages that are reconstituted, is greater than or equal to the
> size of the memslots being dirty logged?
Due to page migration, the values of get_page_stats() are not available (including
pages_2m and pages_1g), and dirty logging can only count the pages that have been
split. It may be possible to use the existing guest_num_pages to construct the
following assert condition:
guest_num_pages <= the number of dirty pages
Do you think this assert condition is correct and enough?
Thanks,
Tao
>
> > }
> >
> > base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> > --
> > 2.34.1
> >
next prev parent reply other threads:[~2024-01-29 8:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 6:40 [PATCH v2] KVM: selftests: Fix dirty_log_page_splitting_test as page migration Tao Su
2024-01-26 20:39 ` Sean Christopherson
2024-01-29 8:21 ` Tao Su [this message]
2024-01-29 17:32 ` Sean Christopherson
2024-01-30 8:04 ` Tao Su
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zbdf+GSYU+5EGfBL@linux.bj.intel.com \
--to=tao1.su@linux.intel.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=yi1.lai@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.