Re: [PATCH] selftests/mm: add THP sysfs interface test

["Lorenzo Stoakes (Oracle)" <ljs@kernel.org>]

On Mon, Mar 16, 2026 at 09:02:33AM -0700, Breno Leitao wrote:
> On Mon, Mar 16, 2026 at 03:44:14PM +0100, David Hildenbrand (Arm) wrote:
> > On 3/16/26 14:47, Breno Leitao wrote:
> > > On Mon, Mar 16, 2026 at 12:55:13PM +0000, Lorenzo Stoakes (Oracle) wrote:
> > >> On Mon, Mar 09, 2026 at 05:00:34AM -0700, Breno Leitao wrote:
> > >>> Add a shell-based selftest that exercises the full set of THP sysfs
> > >>> knobs: enabled (global and per-size anon), defrag, use_zero_page,
> > >>> hpage_pmd_size, shmem_enabled (global and per-size), shrink_underused,
> > >>> khugepaged/ tunables, and per-size stats files.
> > >>>
> > >>> Each writable knob is tested for valid writes, invalid-input rejection,
> > >>> idempotent writes, and mode transitions where applicable. All original
> > >>> values are saved before testing and restored afterwards.
> > >>>
> > >>> The test uses the kselftest KTAP framework (ktap_helpers.sh) for
> > >>> structured TAP 13 output, making results parseable by the kselftest
> > >>> harness. The test plan is printed at the end since the number of test
> > >>> points is dynamic (depends on available hugepage sizes and sysfs files).
> > >>>
> > >>> This is particularly useful for validating the refactoring of
> > >>> enabled_store() and anon_enabled_store() to use sysfs_match_string()
> > >>> and the new change_enabled()/change_anon_orders() helpers.
> > >>>
> > >>> Signed-off-by: Breno Leitao <leitao@debian.org>
> > >>
> > >> The test is broken locally for me, returning error code 127.
> > >>
> > >> I do appreciate the effort here, so I'm sorry to push back negatively, but I
> > >> feel a bash script here is pretty janky, and frankly if any of these interfaces
> > >> were as broken as this it'd be a major failure that would surely get picked up
> > >> far sooner elsewhere.
> > >>
> > >> So while I think this might be useful as a local test for your sysfs interface
> > >> changes, I don't think this is really suited to the mm selftests.
> > >
> > > That is totally fine. This test is what I have been using to test the
> > > changes, and I decide to share it in case someone find it useful.
> > >
> > > Let's drop it.
> >
> > Out of interest, to we know why the test is failing for Lorenzo?
>
> I really don't know, but, it sounds like ktap was not found?

Yeah CONFIG_KUNIT is not set so could be :)

>
> Then the first early-exit path hit:
> ktap_skip_all "..."   # undefined → returns 127 exit "$KSFT_SKIP"
> # expands to: exit "" → exits with last $? = 127
>
> > I agree that the test is a bit excessive, in particular when it comes to
> > invalid/idempotent values etc. I could see some value for testing
> > whether setting the modes keeps working, but also then I wonder if that
> > is really something we'll be changing frequently (and that breaks easily).
>
> yea, I make it very excessive, because there were some intrinsics in
> those sysfs that I was gettingit wrong when doing the intial conversion.
>
> So, the test is something that I trust now, and I found it useful when
> finding regressiosn.
>
> Is is something that will chagne frequently? probably not!
>
> That said, would you like to have a simplified/different version of this
> test?

In an ideal world we'd use kunit or something to assert it internal to the
kernel I guess, but if we do have something scaled down it'd at least be nice to
have in C? :)

I am not sure how useful it'd be though overall, I don't see us changing this
too often and really we're more interested in asserting behaviour.

Sadly THP is inherently tricky to test generally because of its very nature, I
wish we could have better test isolation etc.

See tools/testing/vma for a forlorn dream of kernel code being run in userland
(but oh how the stubs/duplicate declarations/etc. are a pain).

I suspect THP could never be given the same treatment though! :)

Cheers, Lorenzo