From: Sean Christopherson <seanjc@google.com>
To: Tao Su <tao1.su@linux.intel.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, shuah@kernel.org,
yi1.lai@intel.com, David Matlack <dmatlack@google.com>
Subject: Re: [PATCH] KVM: selftests: Add a requirement for disabling numa balancing
Date: Thu, 18 Jan 2024 09:33:29 -0800 [thread overview]
Message-ID: <Zalg6UGBrCe68P-i@google.com> (raw)
In-Reply-To: <Zai6hJgTRegDaSfx@linux.bj.intel.com>
+David
On Thu, Jan 18, 2024, Tao Su wrote:
> On Wed, Jan 17, 2024 at 07:12:08AM -0800, Sean Christopherson wrote:
>
> [...]
>
> > > diff --git a/tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test.c b/tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test.c
> > > index 634c6bfcd572..f2c796111d83 100644
> > > --- a/tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test.c
> > > +++ b/tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test.c
> > > @@ -212,10 +212,21 @@ static void help(char *name)
> > >
> > > int main(int argc, char *argv[])
> > > {
> > > + FILE *f;
> > > int opt;
> > > + int ret, numa_balancing;
> > >
> > > TEST_REQUIRE(get_kvm_param_bool("eager_page_split"));
> > > TEST_REQUIRE(get_kvm_param_bool("tdp_mmu"));
> > > + f = fopen("/proc/sys/kernel/numa_balancing", "r");
> > > + if (f) {
> > > + ret = fscanf(f, "%d", &numa_balancing);
> > > + TEST_ASSERT(ret == 1, "Error reading numa_balancing");
> > > + TEST_ASSERT(!numa_balancing, "please run "
> > > + "'echo 0 > /proc/sys/kernel/numa_balancing'");
> >
> > If we go this route, this should be a TEST_REQUIRE(), not a TEST_ASSERT(). The
> > test hasn't failed, rather it has detected an incompatible setup.
>
> Yes, previously I wanted to print a more user-friendly prompt, but TEST_REQUIRE()
> can’t customize the output…
__TEST_REQUIRE()
> > Something isn't right though. The test defaults to HugeTLB, and the invocation
> > in the changelog doesn't override the backing source. That suggests that NUMA
> > auto-balancing is zapping HugeTLB VMAs, which AFAIK shouldn't happen, e.g. this
> > code in task_numa_work() should cause such VMAs to be skipped:
> >
> > if (!vma_migratable(vma) || !vma_policy_mof(vma) ||
> > is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) {
> > trace_sched_skip_vma_numa(mm, vma, NUMAB_SKIP_UNSUITABLE);
> > continue;
> > }
> >
> > And the test already warns the user if they opt to use something other than
> > HugeTLB.
> >
> > if (!is_backing_src_hugetlb(backing_src)) {
> > pr_info("This test will only work reliably with HugeTLB memory. "
> > "It can work with THP, but that is best effort.\n");
> > }
> >
> > If the test is defaulting to something other than HugeTLB, then we should fix
> > that in the test. If the kernel is doing NUMA balancing on HugeTLB VMAs, then
> > we should fix that in the kernel.
>
> HugeTLB VMAs are not affected by NUMA auto-balancing through my observation, but
> the backing sources of the test code and per-vCPU stacks are not Huge TLB, e.g.
> __vm_create() invokes
>
> vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, 0);
>
> So, some pages are possible to be migrated.
Ah, hmm. Requiring NUMA balancing be disabled isn't going to fix the underlying
issue, it's just guarding against one of the more likely culprits. The best fix
is likely to have the test precisely validate _only_ the test data pages. E.g.
if we double down on requiring HugeTLB, then the test should be able to assert
that it has at least N hugepages when dirty logging is disabled, and at least M
4KiB pages when dirty logging is enabled.
next prev parent reply other threads:[~2024-01-18 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 6:44 [PATCH] KVM: selftests: Add a requirement for disabling numa balancing Tao Su
2024-01-17 15:12 ` Sean Christopherson
2024-01-18 5:43 ` Tao Su
2024-01-18 17:33 ` Sean Christopherson [this message]
2024-01-19 6:05 ` 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=Zalg6UGBrCe68P-i@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=tao1.su@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox