linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Ryan Roberts" <ryan.roberts@arm.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Mark Brown" <broonie@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Florent Revest" <revest@chromium.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 8/8] selftests/mm: Run all tests from run_vmtests.sh
Date: Wed, 19 Jul 2023 16:45:45 -0400	[thread overview]
Message-ID: <ZLhLeSLgYgqSMSEA@x1n> (raw)
In-Reply-To: <5a12536a-2e33-7a68-6cfd-fd991ddf875a@redhat.com>

On Mon, Jul 17, 2023 at 07:27:13PM +0200, David Hildenbrand wrote:
> On 17.07.23 12:31, Ryan Roberts wrote:
> > It is very unclear to me how one is supposed to run all the mm selftests
> > consistently and get clear results.
> > 
> > Most of the test programs are launched by both run_vmtests.sh and
> > run_kselftest.sh:
> > 
> >    hugepage-mmap
> >    hugepage-shm
> >    map_hugetlb
> >    hugepage-mremap
> >    hugepage-vmemmap
> >    hugetlb-madvise
> >    map_fixed_noreplace
> >    gup_test
> >    gup_longterm
> >    uffd-unit-tests
> >    uffd-stress
> >    compaction_test
> >    on-fault-limit
> >    map_populate
> >    mlock-random-test
> >    mlock2-tests
> >    mrelease_test
> >    mremap_test
> >    thuge-gen
> >    virtual_address_range
> >    va_high_addr_switch
> >    mremap_dontunmap
> >    hmm-tests
> >    madv_populate
> >    memfd_secret
> >    ksm_tests
> >    ksm_functional_tests
> >    soft-dirty
> >    cow
> > 
> > However, of this set, when launched by run_vmtests.sh, some of the
> > programs are invoked multiple times with different arguments. When
> > invoked by run_kselftest.sh, they are invoked without arguments (and as
> > a consequence, some fail immediately).
> > 
> > Some test programs are only launched by run_vmtests.sh:
> > 
> >    test_vmalloc.sh
> > 
> > And some test programs and only launched by run_kselftest.sh:
> > 
> >    khugepaged
> >    migration
> >    mkdirty
> >    transhuge-stress
> >    split_huge_page_test
> >    mdwe_test
> >    write_to_hugetlbfs
> > 
> > Furthermore, run_vmtests.sh is invoked by run_kselftest.sh, so in this
> > case all the test programs invoked by both scripts are run twice!
> > 
> > Needless to say, this is a bit of a mess. In the absence of fully
> > understanding the history here, it looks to me like the best solution is
> > to launch ALL test programs from run_vmtests.sh, and ONLY invoke
> > run_vmtests.sh from run_kselftest.sh. This way, we get full control over
> > the parameters, each program is only invoked the intended number of
> > times, and regardless of which script is used, the same tests get run in
> > the same way.
> > 
> > The only drawback is that if using run_kselftest.sh, it's top-level tap
> > result reporting reports only a single test and it fails if any of the
> > contained tests fail. I don't see this as a big deal though since we
> > still see all the nested reporting from multiple layers. The other issue
> > with this is that all of run_vmtests.sh must execute within a single
> > kselftest timeout period, so let's increase that to something more
> > suitable.
> > 
> > In the Makefile, TEST_GEN_PROGS will compile and install the tests and
> > will add them to the list of tests that run_kselftest.sh will run.
> > TEST_GEN_FILES will compile and install the tests but will not add them
> > to the test list. So let's move all the programs from TEST_GEN_PROGS to
> > TEST_GEN_FILES so that they are built but not executed by
> > run_kselftest.sh. Note that run_vmtests.sh is added to TEST_PROGS, which
> > means it ends up in the test list. (the lack of "_GEN" means it won't be
> > compiled, but simply copied).
> > 
> > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> > ---
> 
> Acked-by: David Hildenbrand <david@redhat.com>

Thanks for letting me know, David.  Sorry for the late response, still
catching up things.

I used to justify that from mm/ itself that everything should be PROG, but
I see that from higher level where TEST_GEN_FILE|PROG is really used this
makes sense.  As long as vm_utils.o will be properly linked I'll be happy
enough..

Acked-by: Peter Xu <peterx@redhat.com>

Thanks,

-- 
Peter Xu



  reply	other threads:[~2023-07-19 20:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 10:31 [PATCH v2 0/8] selftests/mm fixes for arm64 Ryan Roberts
2023-07-17 10:31 ` [PATCH v2 1/8] selftests: Line buffer test program's stdout Ryan Roberts
2023-07-17 17:22   ` Mark Brown
2023-07-17 10:31 ` [PATCH v2 2/8] selftests/mm: Skip soft-dirty tests on arm64 Ryan Roberts
2023-07-17 17:20   ` David Hildenbrand
2023-07-17 10:31 ` [PATCH v2 3/8] selftests/mm: Enable mrelease_test for arm64 Ryan Roberts
2023-07-17 10:31 ` [PATCH v2 4/8] selftests/mm: Fix thuge-gen test bugs Ryan Roberts
2023-07-17 17:22   ` David Hildenbrand
2023-07-17 10:31 ` [PATCH v2 5/8] selftests/mm: va_high_addr_switch should skip unsupported arm64 configs Ryan Roberts
2023-07-17 10:31 ` [PATCH v2 6/8] selftests/mm: Make migration test robust to failure Ryan Roberts
2023-07-17 17:40   ` David Hildenbrand
2023-07-18 10:49     ` Ryan Roberts
2023-07-18 11:23       ` David Hildenbrand
2023-07-18 11:24         ` David Hildenbrand
2023-07-18 12:42           ` Ryan Roberts
2023-07-18 15:24             ` David Hildenbrand
2023-07-17 10:31 ` [PATCH v2 7/8] selftests/mm: Optionally pass duration to transhuge-stress Ryan Roberts
2023-07-17 17:24   ` David Hildenbrand
2023-07-17 10:31 ` [PATCH v2 8/8] selftests/mm: Run all tests from run_vmtests.sh Ryan Roberts
2023-07-17 17:27   ` David Hildenbrand
2023-07-19 20:45     ` Peter Xu [this message]
2023-07-20  8:14       ` Ryan Roberts

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=ZLhLeSLgYgqSMSEA@x1n \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=david@redhat.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=revest@chromium.org \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@kernel.org \
    /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