Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1190334 > unrolled thread

Re: [PATCH v4 00/10] hugetlbfs: add fallocate support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Davidlohr Bueso <dave@stgolabs.net> - 2015-07-23 00:30 +0200
    Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Andrew Morton <akpm@linux-foundation.org> - 2015-07-23 00:40 +0200
      Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Andrew Morton <akpm@linux-foundation.org> - 2015-07-23 00:40 +0200
        Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Davidlohr Bueso <dave@stgolabs.net> - 2015-07-23 01:00 +0200
          Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Davidlohr Bueso <dave@stgolabs.net> - 2015-07-23 01:00 +0200
      Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Davidlohr Bueso <dave@stgolabs.net> - 2015-07-23 00:40 +0200
      Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Mike Kravetz <mike.kravetz@oracle.com> - 2015-07-23 01:30 +0200
        Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Davidlohr Bueso <dave@stgolabs.net> - 2015-07-23 02:00 +0200
          Re: [PATCH v4 00/10] hugetlbfs: add fallocate support David Rientjes <rientjes@google.com> - 2015-07-23 02:10 +0200
        Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Mike Kravetz <mike.kravetz@oracle.com> - 2015-07-23 19:10 +0200
          Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Eric B Munson <emunson@akamai.com> - 2015-07-23 19:20 +0200
            Re: [PATCH v4 00/10] hugetlbfs: add fallocate support Mike Kravetz <mike.kravetz@oracle.com> - 2015-07-23 19:40 +0200

#1190334 — Re: [PATCH v4 00/10] hugetlbfs: add fallocate support

On Wed, 2015-07-22 at 15:06 -0700, Andrew Morton wrote:
> On Tue, 21 Jul 2015 11:09:34 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 
> > As suggested during the RFC process, tests have been proposed to
> > libhugetlbfs as described at:
> > http://librelist.com/browser//libhugetlbfs/2015/6/25/patch-tests-add-tests-for-fallocate-system-call/

Great!

> 
> I didn't know that libhugetlbfs has tests.  I wonder if that makes
> tools/testing/selftests/vm's hugetlbfstest harmful?

Why harmful? Redundant, maybe(?). Does anyone even use selftests for
hugetlbfs regression testing? Lets see, we also have these:

- hugepage-{mmap,shm}.c
- map_hugetlb.c

There's probably a lot of room for improvement here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1190335

On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:

> > 
> > I didn't know that libhugetlbfs has tests.  I wonder if that makes
> > tools/testing/selftests/vm's hugetlbfstest harmful?
> 
> Why harmful? Redundant, maybe(?).

The presence of the in-kernel tests will cause people to add stuff to
them when it would be better if they were to apply that effort to
making libhugetlbfs better.  Or vice versa.

Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
the kernel selftest and says "yay, everything works", unaware that they
just broke fallocate support.

> Does anyone even use selftests for
> hugetlbfs regression testing? Lets see, we also have these:
> 
> - hugepage-{mmap,shm}.c
> - map_hugetlb.c
> 
> There's probably a lot of room for improvement here.

selftests is a pretty scrappy place.  It's partly a dumping ground for
things so useful test code doesn't just get lost and bitrotted.  Partly
a framework so people who add features can easily test them. Partly to
provide tools to architecture maintainers when they wire up new
syscalls and the like.

Unless there's some good reason to retain the hugetlb part of
selftests, I'm thinking we should just remove it to avoid
distracting/misleading people.  Or possibly move the libhugetlbfs test
code into the kernel tree and maintain it there.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190337

On Wed, 22 Jul 2015 15:34:34 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:

> On Wed, 2015-07-22 at 15:30 -0700, Andrew Morton wrote:
> > selftests is a pretty scrappy place.  It's partly a dumping ground for
> > things so useful test code doesn't just get lost and bitrotted.  Partly
> > a framework so people who add features can easily test them. Partly to
> > provide tools to architecture maintainers when they wire up new
> > syscalls and the like.
> 
> Yeah, ipc, for instance, also sucks _badly_ in selftests.

What testsuite should people be using for IPC?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190344

On Wed, 2015-07-22 at 15:37 -0700, Andrew Morton wrote:
> On Wed, 22 Jul 2015 15:34:34 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
> 
> > On Wed, 2015-07-22 at 15:30 -0700, Andrew Morton wrote:
> > > selftests is a pretty scrappy place.  It's partly a dumping ground for
> > > things so useful test code doesn't just get lost and bitrotted.  Partly
> > > a framework so people who add features can easily test them. Partly to
> > > provide tools to architecture maintainers when they wire up new
> > > syscalls and the like.
> > 
> > Yeah, ipc, for instance, also sucks _badly_ in selftests.
> 
> What testsuite should people be using for IPC?

The best I've found is using the ipc parts of LTP. It's caught a lot of
bugs in the past. Unsurprisingly, I believe Fengguang has this
automated.

Manfred also has a few for more specific purposes -- which also serve
for performance testing:
https://github.com/manfred-colorfu/ipcsemtest
https://github.com/manfred-colorfu/ipcscale

iirc Dave Hansen also had written some shm-specific tests.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190347

On Wed, 2015-07-22 at 15:50 -0700, Davidlohr Bueso wrote:
> On Wed, 2015-07-22 at 15:37 -0700, Andrew Morton wrote:
> > On Wed, 22 Jul 2015 15:34:34 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
> > 
> > > On Wed, 2015-07-22 at 15:30 -0700, Andrew Morton wrote:
> > > > selftests is a pretty scrappy place.  It's partly a dumping ground for
> > > > things so useful test code doesn't just get lost and bitrotted.  Partly
> > > > a framework so people who add features can easily test them. Partly to
> > > > provide tools to architecture maintainers when they wire up new
> > > > syscalls and the like.
> > > 
> > > Yeah, ipc, for instance, also sucks _badly_ in selftests.
> > 
> > What testsuite should people be using for IPC?
> 
> The best I've found is using the ipc parts of LTP. It's caught a lot of
> bugs in the past. Unsurprisingly, I believe Fengguang has this
> automated.
> 
> Manfred also has a few for more specific purposes -- which also serve
> for performance testing:
> https://github.com/manfred-colorfu/ipcsemtest
> https://github.com/manfred-colorfu/ipcscale
> 
> iirc Dave Hansen also had written some shm-specific tests.

I also used to rely on multiple Oracle 11g RDBMS workloads and
benchmarks, particularly for dealing with sysv sems. Unfortunately I no
longer have the required licenses :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190339

On Wed, 2015-07-22 at 15:30 -0700, Andrew Morton wrote:
> selftests is a pretty scrappy place.  It's partly a dumping ground for
> things so useful test code doesn't just get lost and bitrotted.  Partly
> a framework so people who add features can easily test them. Partly to
> provide tools to architecture maintainers when they wire up new
> syscalls and the like.

Yeah, ipc, for instance, also sucks _badly_ in selftests.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190351

On 07/22/2015 03:30 PM, Andrew Morton wrote:
> On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
>
>>>
>>> I didn't know that libhugetlbfs has tests.  I wonder if that makes
>>> tools/testing/selftests/vm's hugetlbfstest harmful?
>>
>> Why harmful? Redundant, maybe(?).
>
> The presence of the in-kernel tests will cause people to add stuff to
> them when it would be better if they were to apply that effort to
> making libhugetlbfs better.  Or vice versa.
>
> Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
> the kernel selftest and says "yay, everything works", unaware that they
> just broke fallocate support.
>
>> Does anyone even use selftests for
>> hugetlbfs regression testing? Lets see, we also have these:
>>
>> - hugepage-{mmap,shm}.c
>> - map_hugetlb.c
>>
>> There's probably a lot of room for improvement here.
>
> selftests is a pretty scrappy place.  It's partly a dumping ground for
> things so useful test code doesn't just get lost and bitrotted.  Partly
> a framework so people who add features can easily test them. Partly to
> provide tools to architecture maintainers when they wire up new
> syscalls and the like.
>
> Unless there's some good reason to retain the hugetlb part of
> selftests, I'm thinking we should just remove it to avoid
> distracting/misleading people.  Or possibly move the libhugetlbfs test
> code into the kernel tree and maintain it there.

Adding Eric as he is the libhugetlbfs maintainer.

I think removing the hugetlb selftests in the kernel and pointing
people to libhugetlbfs is the way to go.  From a very quick scan
of the selftests, I would guess libhugetlbfs covers everything
in those tests.

I'm willing to verify the testing provided by selftests is included
in libhugetlbfs, and remove selftests if that is the direction we
want to take.

-- 
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190371

On Wed, 2015-07-22 at 16:18 -0700, Mike Kravetz wrote:
> On 07/22/2015 03:30 PM, Andrew Morton wrote:
> > On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
> >
> >>>
> >>> I didn't know that libhugetlbfs has tests.  I wonder if that makes
> >>> tools/testing/selftests/vm's hugetlbfstest harmful?
> >>
> >> Why harmful? Redundant, maybe(?).
> >
> > The presence of the in-kernel tests will cause people to add stuff to
> > them when it would be better if they were to apply that effort to
> > making libhugetlbfs better.  Or vice versa.
> >
> > Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
> > the kernel selftest and says "yay, everything works", unaware that they
> > just broke fallocate support.
> >
> >> Does anyone even use selftests for
> >> hugetlbfs regression testing? Lets see, we also have these:
> >>
> >> - hugepage-{mmap,shm}.c
> >> - map_hugetlb.c
> >>
> >> There's probably a lot of room for improvement here.
> >
> > selftests is a pretty scrappy place.  It's partly a dumping ground for
> > things so useful test code doesn't just get lost and bitrotted.  Partly
> > a framework so people who add features can easily test them. Partly to
> > provide tools to architecture maintainers when they wire up new
> > syscalls and the like.
> >
> > Unless there's some good reason to retain the hugetlb part of
> > selftests, I'm thinking we should just remove it to avoid
> > distracting/misleading people.  Or possibly move the libhugetlbfs test
> > code into the kernel tree and maintain it there.
> 
> Adding Eric as he is the libhugetlbfs maintainer.
> 
> I think removing the hugetlb selftests in the kernel and pointing
> people to libhugetlbfs is the way to go.  From a very quick scan
> of the selftests, I would guess libhugetlbfs covers everything
> in those tests.

fwiw, I've been trying to push people towards this for a while. Ie:

commit 15610c86fa83ff778eb80d3cfaa71d6acceb628a
Author: Davidlohr Bueso <davidlohr@hp.com>
Date:   Wed Sep 11 14:21:48 2013 -0700

    hugepage: mention libhugetlbfs in doc
    
    Explicitly mention/recommend using the libhugetlbfs test cases when
    changing related kernel code.  Developers that are unaware of the project
    can easily miss this and introduce potential regressions that may or may
    not be caught by community review.
    
    Also do some cleanups that make the document visually easier to view at a
    first glance.
    
    Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

But generally speaking, I doubt this doc is read much.

> 
> I'm willing to verify the testing provided by selftests is included
> in libhugetlbfs, and remove selftests if that is the direction we
> want to take.

Ack to this idea and thanks for volunteering.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190379

On Wed, 22 Jul 2015, Davidlohr Bueso wrote:

> fwiw, I've been trying to push people towards this for a while. Ie:
> 
> commit 15610c86fa83ff778eb80d3cfaa71d6acceb628a
> Author: Davidlohr Bueso <davidlohr@hp.com>
> Date:   Wed Sep 11 14:21:48 2013 -0700
> 
>     hugepage: mention libhugetlbfs in doc
>     
>     Explicitly mention/recommend using the libhugetlbfs test cases when
>     changing related kernel code.  Developers that are unaware of the project
>     can easily miss this and introduce potential regressions that may or may
>     not be caught by community review.
>     
>     Also do some cleanups that make the document visually easier to view at a
>     first glance.
>     
>     Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> But generally speaking, I doubt this doc is read much.
> 

The mmap(2) man page cites it specifically as the source of information on 
MAP_HUGETLB and it, in turn, directs people to 
tools/testing/selftests/vm/map_hugetlb.c.  It also mentions libhugetlbfs 
as a result of your patch, so perhaps change the man page to point people 
directly there?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1191138

On 07/23/2015 08:17 AM, Eric B Munson wrote:
> On Wed, 22 Jul 2015, Mike Kravetz wrote:
>
>> On 07/22/2015 03:30 PM, Andrew Morton wrote:
>>> On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
>>>
>>>>>
>>>>> I didn't know that libhugetlbfs has tests.  I wonder if that makes
>>>>> tools/testing/selftests/vm's hugetlbfstest harmful?
>>>>
>>>> Why harmful? Redundant, maybe(?).
>>>
>>> The presence of the in-kernel tests will cause people to add stuff to
>>> them when it would be better if they were to apply that effort to
>>> making libhugetlbfs better.  Or vice versa.
>>>
>>> Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
>>> the kernel selftest and says "yay, everything works", unaware that they
>>> just broke fallocate support.
>>>
>>>> Does anyone even use selftests for
>>>> hugetlbfs regression testing? Lets see, we also have these:
>>>>
>>>> - hugepage-{mmap,shm}.c
>>>> - map_hugetlb.c
>>>>
>>>> There's probably a lot of room for improvement here.
>>>
>>> selftests is a pretty scrappy place.  It's partly a dumping ground for
>>> things so useful test code doesn't just get lost and bitrotted.  Partly
>>> a framework so people who add features can easily test them. Partly to
>>> provide tools to architecture maintainers when they wire up new
>>> syscalls and the like.
>>>
>>> Unless there's some good reason to retain the hugetlb part of
>>> selftests, I'm thinking we should just remove it to avoid
>>> distracting/misleading people.  Or possibly move the libhugetlbfs test
>>> code into the kernel tree and maintain it there.
>>
>> Adding Eric as he is the libhugetlbfs maintainer.
>>
>> I think removing the hugetlb selftests in the kernel and pointing
>> people to libhugetlbfs is the way to go.  From a very quick scan
>> of the selftests, I would guess libhugetlbfs covers everything
>> in those tests.
>>
>> I'm willing to verify the testing provided by selftests is included
>> in libhugetlbfs, and remove selftests if that is the direction we
>> want to take.
>
> I would rather see the test suite stay in the library, there are a
> number of tests that rely on infrastructure in the library that is not
> available in selftests.
>
> I am happy to help with any tests that need to be added/modified in the
> library to cover.

I thought about this some more and think there are two distinct
groups of users that should be considered.
1) Application developers who simply want to use hugetlb
2) Kernel developers who are modifying hugetlb related code

The application developers will mostly want information in the
man pages, hugetlbpage.txt and hugetlb selftest programs to use
as sample code to get started.  They can also use libhugetlbfs
man pages/library if they desire.  Because of this, I do not
really want to remove the hugetlb selftest programs.  There are
no equivalent simple stand alone programs in libhugetlbfs.

Kernel developers would be more concerned about introducing
regressions.  The selftest programs are of limited use for this
purpose.  The libhugetlbfs test suite is much more suited for
regression testing.

With this in mind, I suggest:
- Keep the mmap man page reference to Documentation/vm/hugetlbpage.txt
- Small modification to hugetlbpage.txt saying the selftest code is
   good for application development examples.  And, kernel developers
   should use libhugetlbfs test suite for regression testing.  In any
   case, the sourceforge URL for libhugetlbfs is no longer valid and
   needs to be updated.
- Modify the run_vmtests selftest script to print out a message saying
   libhugetlbfs should be used for hugetlb regression testing.  This
   would help catch people who might think the few selftests are
   sufficient.

Thoughts?
-- 
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1191154

[Multipart message — attachments visible in raw view] — view raw

On Thu, 23 Jul 2015, Mike Kravetz wrote:

> On 07/23/2015 08:17 AM, Eric B Munson wrote:
> >On Wed, 22 Jul 2015, Mike Kravetz wrote:
> >
> >>On 07/22/2015 03:30 PM, Andrew Morton wrote:
> >>>On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
> >>>
> >>>>>
> >>>>>I didn't know that libhugetlbfs has tests.  I wonder if that makes
> >>>>>tools/testing/selftests/vm's hugetlbfstest harmful?
> >>>>
> >>>>Why harmful? Redundant, maybe(?).
> >>>
> >>>The presence of the in-kernel tests will cause people to add stuff to
> >>>them when it would be better if they were to apply that effort to
> >>>making libhugetlbfs better.  Or vice versa.
> >>>
> >>>Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
> >>>the kernel selftest and says "yay, everything works", unaware that they
> >>>just broke fallocate support.
> >>>
> >>>>Does anyone even use selftests for
> >>>>hugetlbfs regression testing? Lets see, we also have these:
> >>>>
> >>>>- hugepage-{mmap,shm}.c
> >>>>- map_hugetlb.c
> >>>>
> >>>>There's probably a lot of room for improvement here.
> >>>
> >>>selftests is a pretty scrappy place.  It's partly a dumping ground for
> >>>things so useful test code doesn't just get lost and bitrotted.  Partly
> >>>a framework so people who add features can easily test them. Partly to
> >>>provide tools to architecture maintainers when they wire up new
> >>>syscalls and the like.
> >>>
> >>>Unless there's some good reason to retain the hugetlb part of
> >>>selftests, I'm thinking we should just remove it to avoid
> >>>distracting/misleading people.  Or possibly move the libhugetlbfs test
> >>>code into the kernel tree and maintain it there.
> >>
> >>Adding Eric as he is the libhugetlbfs maintainer.
> >>
> >>I think removing the hugetlb selftests in the kernel and pointing
> >>people to libhugetlbfs is the way to go.  From a very quick scan
> >>of the selftests, I would guess libhugetlbfs covers everything
> >>in those tests.
> >>
> >>I'm willing to verify the testing provided by selftests is included
> >>in libhugetlbfs, and remove selftests if that is the direction we
> >>want to take.
> >
> >I would rather see the test suite stay in the library, there are a
> >number of tests that rely on infrastructure in the library that is not
> >available in selftests.
> >
> >I am happy to help with any tests that need to be added/modified in the
> >library to cover.
> 
> I thought about this some more and think there are two distinct
> groups of users that should be considered.
> 1) Application developers who simply want to use hugetlb
> 2) Kernel developers who are modifying hugetlb related code
> 
> The application developers will mostly want information in the
> man pages, hugetlbpage.txt and hugetlb selftest programs to use
> as sample code to get started.  They can also use libhugetlbfs
> man pages/library if they desire.  Because of this, I do not
> really want to remove the hugetlb selftest programs.  There are
> no equivalent simple stand alone programs in libhugetlbfs.
> 
> Kernel developers would be more concerned about introducing
> regressions.  The selftest programs are of limited use for this
> purpose.  The libhugetlbfs test suite is much more suited for
> regression testing.
> 
> With this in mind, I suggest:
> - Keep the mmap man page reference to Documentation/vm/hugetlbpage.txt
> - Small modification to hugetlbpage.txt saying the selftest code is
>   good for application development examples.  And, kernel developers
>   should use libhugetlbfs test suite for regression testing.  In any
>   case, the sourceforge URL for libhugetlbfs is no longer valid and
>   needs to be updated.
> - Modify the run_vmtests selftest script to print out a message saying
>   libhugetlbfs should be used for hugetlb regression testing.  This
>   would help catch people who might think the few selftests are
>   sufficient.
> 
> Thoughts?

There are a number of tests in the libhugetlbfs suite that cover kernel
problems, are you suggesting that we move all these tests out of
libhugetlbfs and into selftests?  I don't think we should separate the
responsibility for testing kernel regressions so where ever they end up,
they should all be together.  The libhugetlbfs suite has some nice
features for setting up the test environment (consider that a plug to
move tests in that direction).

[toc] | [prev] | [next] | [standalone]

#1191173

On 07/23/2015 10:17 AM, Eric B Munson wrote:
> On Thu, 23 Jul 2015, Mike Kravetz wrote:
>
>> On 07/23/2015 08:17 AM, Eric B Munson wrote:
>>> On Wed, 22 Jul 2015, Mike Kravetz wrote:
>>>
>>>> On 07/22/2015 03:30 PM, Andrew Morton wrote:
>>>>> On Wed, 22 Jul 2015 15:19:54 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
>>>>>
>>>>>>>
>>>>>>> I didn't know that libhugetlbfs has tests.  I wonder if that makes
>>>>>>> tools/testing/selftests/vm's hugetlbfstest harmful?
>>>>>>
>>>>>> Why harmful? Redundant, maybe(?).
>>>>>
>>>>> The presence of the in-kernel tests will cause people to add stuff to
>>>>> them when it would be better if they were to apply that effort to
>>>>> making libhugetlbfs better.  Or vice versa.
>>>>>
>>>>> Mike's work is an example.  Someone later makes a change to hugetlbfs, runs
>>>>> the kernel selftest and says "yay, everything works", unaware that they
>>>>> just broke fallocate support.
>>>>>
>>>>>> Does anyone even use selftests for
>>>>>> hugetlbfs regression testing? Lets see, we also have these:
>>>>>>
>>>>>> - hugepage-{mmap,shm}.c
>>>>>> - map_hugetlb.c
>>>>>>
>>>>>> There's probably a lot of room for improvement here.
>>>>>
>>>>> selftests is a pretty scrappy place.  It's partly a dumping ground for
>>>>> things so useful test code doesn't just get lost and bitrotted.  Partly
>>>>> a framework so people who add features can easily test them. Partly to
>>>>> provide tools to architecture maintainers when they wire up new
>>>>> syscalls and the like.
>>>>>
>>>>> Unless there's some good reason to retain the hugetlb part of
>>>>> selftests, I'm thinking we should just remove it to avoid
>>>>> distracting/misleading people.  Or possibly move the libhugetlbfs test
>>>>> code into the kernel tree and maintain it there.
>>>>
>>>> Adding Eric as he is the libhugetlbfs maintainer.
>>>>
>>>> I think removing the hugetlb selftests in the kernel and pointing
>>>> people to libhugetlbfs is the way to go.  From a very quick scan
>>>> of the selftests, I would guess libhugetlbfs covers everything
>>>> in those tests.
>>>>
>>>> I'm willing to verify the testing provided by selftests is included
>>>> in libhugetlbfs, and remove selftests if that is the direction we
>>>> want to take.
>>>
>>> I would rather see the test suite stay in the library, there are a
>>> number of tests that rely on infrastructure in the library that is not
>>> available in selftests.
>>>
>>> I am happy to help with any tests that need to be added/modified in the
>>> library to cover.
>>
>> I thought about this some more and think there are two distinct
>> groups of users that should be considered.
>> 1) Application developers who simply want to use hugetlb
>> 2) Kernel developers who are modifying hugetlb related code
>>
>> The application developers will mostly want information in the
>> man pages, hugetlbpage.txt and hugetlb selftest programs to use
>> as sample code to get started.  They can also use libhugetlbfs
>> man pages/library if they desire.  Because of this, I do not
>> really want to remove the hugetlb selftest programs.  There are
>> no equivalent simple stand alone programs in libhugetlbfs.
>>
>> Kernel developers would be more concerned about introducing
>> regressions.  The selftest programs are of limited use for this
>> purpose.  The libhugetlbfs test suite is much more suited for
>> regression testing.
>>
>> With this in mind, I suggest:
>> - Keep the mmap man page reference to Documentation/vm/hugetlbpage.txt
>> - Small modification to hugetlbpage.txt saying the selftest code is
>>    good for application development examples.  And, kernel developers
>>    should use libhugetlbfs test suite for regression testing.  In any
>>    case, the sourceforge URL for libhugetlbfs is no longer valid and
>>    needs to be updated.
>> - Modify the run_vmtests selftest script to print out a message saying
>>    libhugetlbfs should be used for hugetlb regression testing.  This
>>    would help catch people who might think the few selftests are
>>    sufficient.
>>
>> Thoughts?
>
> There are a number of tests in the libhugetlbfs suite that cover kernel
> problems, are you suggesting that we move all these tests out of
> libhugetlbfs and into selftests?  I don't think we should separate the
> responsibility for testing kernel regressions so where ever they end up,
> they should all be together.  The libhugetlbfs suite has some nice
> features for setting up the test environment (consider that a plug to
> move tests in that direction).

No, not suggesting we move anything out of libhugetlbfs.  I believe
that should be the primary test suite for hugetlb.

However, the few programs in selftest do provide some value IMO.
They are examples of hugetlb usage without any of the libhugetlbfs
infrastructure present.  Ideally, there would be some place to put
this sample code.  I can not think of an ideal location.

-- 
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web