linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"Shuah Khan" <shuah@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 8/8] selftests/vm: hmm-tests: remove the libhugetlbfs dependency
Date: Mon, 28 Sep 2020 13:18:55 -0700	[thread overview]
Message-ID: <982fd9bf-64cb-00e9-f092-13849c7cf7d9@nvidia.com> (raw)
In-Reply-To: <20200928130245.GQ9916@ziepe.ca>

On 9/28/20 6:02 AM, Jason Gunthorpe wrote:
> On Sun, Sep 27, 2020 at 11:21:59PM -0700, John Hubbard wrote:
...
>> +gcc -c $tmpfile_c -o $tmpfile_o >/dev/null 2>&1
> 
> This gcc has to come from some makefile variable

ahem, yes, that really should have just been $(CC), will change to that.

> 
> This is kind of janky :\
> 
> Could we just not use libhugetlbfs? Doesn't it all just boil down to
> creating a file in /dev/huge? Eg look at tools/testing/selftests/vm/hugepage-mmap.c
> 

Well, the situation is a lot worse than that, because hmm-tests.c is using a few
helper functions that end up pulling in more and more.

My first attempt was actually in your direction: just grab a bit of code from the
library and drop it in. But that ended up turning into several pages of code from
quite a few functions and definitions, and it was looking maybe excessive. (I
can look at it again, though. Maybe it feels less excessive if there are no other
acceptible alternatives.)

So then I thought, why not just *delete* those two routines from hmm-tests.c? But
Ralph didn't like that because he notes that hmm_range_fault() loses some useful
test coverage by being exercised with hugetlbfs.

So finally I landed here, which is so far, the smallest change that would be
potentially acceptible: a couple dozen lines, in order to selectively disable the
problematic routines.

Anyway, thoughts? I like the current approach but am open to anything that makes
hmm-test Just Work for more people, on the *first* try.

thanks,
-- 
John Hubbard
NVIDIA


  reply	other threads:[~2020-09-28 20:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28  6:21 [PATCH 0/8] selftests/vm: gup_test, hmm-tests, assorted improvements John Hubbard
2020-09-28  6:21 ` [PATCH 1/8] mm/gup_benchmark: rename to mm/gup_test John Hubbard
2020-09-28  6:21 ` [PATCH 2/8] selftests/vm: use a common gup_test.h John Hubbard
2020-09-28 12:57   ` Jason Gunthorpe
2020-09-28 20:10     ` John Hubbard
2020-09-29 16:35       ` Jason Gunthorpe
2020-09-29 17:44         ` John Hubbard
2020-09-29 17:55           ` Jason Gunthorpe
2020-09-29 18:59             ` John Hubbard
2020-09-29 19:08               ` Jason Gunthorpe
2020-09-29 19:48                 ` John Hubbard
2020-09-29 19:53                   ` Jason Gunthorpe
2020-09-29 20:00                     ` Shuah Khan
2020-09-29 20:11                       ` John Hubbard
2020-09-29 20:20                         ` Shuah Khan
2020-09-29 20:36                           ` John Hubbard
2020-09-28  6:21 ` [PATCH 3/8] selftests/vm: rename run_vmtests --> run_vmtests.sh John Hubbard
2020-09-28  6:21 ` [PATCH 4/8] selftests/vm: minor cleanup: Makefile and gup_test.c John Hubbard
2020-09-28  6:21 ` [PATCH 5/8] selftests/vm: only some gup_test items are really benchmarks John Hubbard
2020-09-28  6:21 ` [PATCH 6/8] selftests/vm: gup_test: introduce the dump_pages() sub-test John Hubbard
2020-09-28 19:25   ` Ira Weiny
2020-09-28  6:21 ` [PATCH 7/8] selftests/vm: run_vmtest.sh: update and clean up gup_test invocation John Hubbard
2020-09-28 19:26   ` Ira Weiny
2020-09-28 19:58     ` John Hubbard
2020-09-28  6:21 ` [PATCH 8/8] selftests/vm: hmm-tests: remove the libhugetlbfs dependency John Hubbard
2020-09-28 13:02   ` Jason Gunthorpe
2020-09-28 20:18     ` John Hubbard [this message]
2020-09-28 20:45       ` John Hubbard

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=982fd9bf-64cb-00e9-f092-13849c7cf7d9@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=rcampbell@nvidia.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