linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Shuah Khan <shuah@kernel.org>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/mm: Fix test result reporting in gup_longterm
Date: Wed, 21 May 2025 19:48:35 +0100	[thread overview]
Message-ID: <e7cb18c4-fed3-4fa5-bb51-228f2b018ce9@sirena.org.uk> (raw)
In-Reply-To: <8131ce62-0cee-455f-9eeb-e2bbed244402@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On Mon, May 19, 2025 at 03:28:47PM +0200, David Hildenbrand wrote:
> On 16.05.25 20:07, Mark Brown wrote:
> > On Fri, May 16, 2025 at 04:12:08PM +0200, David Hildenbrand wrote:

> > [Converting to kselftet_harness]
> > > > That'd certainly work, though doing that is more surgery on the test
> > > > than I personally have the time/enthusiasm for right now.

> > > Same over here.

> > > But probably if we touch it, we should just clean it up right away. Well,
> > > if we decide that that is the right cleanup. (you mention something like that
> > > in your patch description :)

> > OTOH there's something to be said for just making incremental
> > improvements in the tests where we can, they tend not to get huge
> > amounts of love in general which means perfect can very much be the

> I would agree if it would be a handful of small changes.

> But here we are already at

>  1 file changed, 107 insertions(+), 56 deletions(-)

So, I did have a brief poke at this which confirmed my instinct that
blocking a fix for this (and the other similarly structured tests like
cow) seems disproportionate.  

The biggest issue is the configuration of fixtures, the harness really
wants the set of test variants to be fixed at compile time (see the
FIXTURE_ macros) but we're covering the dynamically discovered list of
huge page sizes.  I'm not seeing a super tasteful way to deal with that
mismatch of assumptions, the most obvious thing is to switch to having a
static list of possible huge page sizes and skipping if that size isn't
there but there's an awful lot of potential huge page sizes most of
which won't appear on any given system.  That'd be both ugly code and
bad ergonomics for anyone actively working with the test.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2025-05-21 18:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15  8:57 Mark Brown
2025-05-15  9:35 ` Dev Jain
2025-05-15  9:41   ` Mark Brown
2025-05-15  9:43     ` Dev Jain
2025-05-16  8:02 ` David Hildenbrand
2025-05-16 12:29   ` Mark Brown
2025-05-16 12:55     ` David Hildenbrand
2025-05-16 13:09       ` Mark Brown
2025-05-16 14:12         ` David Hildenbrand
2025-05-16 18:07           ` Mark Brown
2025-05-19 13:28             ` David Hildenbrand
2025-05-19 14:55               ` Mark Brown
2025-05-21 18:48               ` Mark Brown [this message]
2025-05-22  8:42                 ` David Hildenbrand
2025-05-22  9:23                   ` Mark Brown

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=e7cb18c4-fed3-4fa5-bb51-228f2b018ce9@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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