Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220705185605.3889110-1-jsavitz@redhat.com> <20220705133456.d5572b2e36ebb36188369988@linux-foundation.org>
In-Reply-To: <20220705133456.d5572b2e36ebb36188369988@linux-foundation.org>
From:   Nico Pache <npache@redhat.com>
Date:   Wed, 6 Jul 2022 14:38:03 -0400
Message-ID: <CAA1CXcAFyMLBEi87A0+pBbUKtzfEeE-5uyqPugmHLmzgH8=w8w@mail.gmail.com>
Subject: Re: [PATCH] selftests/vm: enable running select groups of tests
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Joel Savitz <jsavitz@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Shuah Khan <shuah@kernel.org>, Linux MM <linux-mm@kvack.org>,
        linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jul 5, 2022 at 4:35 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue,  5 Jul 2022 14:56:05 -0400 Joel Savitz <jsavitz@redhat.com> wrote:
>
> > Add the ability to run one or more groups of vm tests (specified
> > by the environment variable TEST_ITEMS). Preserve existing default
> > behavior of running all tests when TEST_ITEMS is empty or "default".
>
Hi Andrew,

> What is the reason for this?  What's the use case?

The current design of vm selftests is all-or-none. We'd like to be
able to selectively run these tests (We settled for selective groups
of tests rather than individual tests).

The main reason for doing this is our efforts to expand RedHats MM CI
testing. There are two use cases for these changes that relate to our
reasoning:
1) Our current CI has overlapping tests between LTP and vm selftests,
so we'd like a way to prevent running the same test in two places.
2) We'd like the ability to skip a test if it is determined to be
unstable or requires certain hardware requirements.

By adding this functionality we are really expanding what we are able
to do with the stock vm-selftests.

> And why via the environment rather than via commandline args?
Just a design choice I suppose. I'm sure Joel would be willing to
implement it as a cmdline arg if you'd prefer that approach.

Cheers,
-- Nico