[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca035fbb-752d-70ff-1be8-e2d2f90b3c0e@oracle.com>
Date: Tue, 17 Dec 2019 10:05:06 -0800
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Michal Hocko <mhocko@...nel.org>, Waiman Long <longman@...hat.com>,
Eric B Munson <emunson@...mai.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
aneesh.kumar@...ux.ibm.com, Jarod Wilson <jarod@...hat.com>
Subject: Re: [PATCH v2] mm/hugetlb: defer free_huge_page() to a workqueue
Cc: Eric
On 12/17/19 1:00 AM, Michal Hocko wrote:
> On Mon 16-12-19 13:44:53, Waiman Long wrote:
>> On 12/16/19 10:38 AM, Waiman Long wrote:
> [...]
>>>> Can you extract guts of the testcase and integrate them into hugetlb
>>>> test suite?
>>
>> BTW, what hugetlb test suite are you talking about?
>
> I was using tests from libhugetlbfs package in the past. There are few
> tests in LTP project but the libhugetlbfs coverage used to cover the
> largest part of the functionality.
>
> Is there any newer home for the package than [1], Mike? Btw. would it
> mak sense to migrate those tests to a more common place, LTP or kernel
> selftests?
That is the latest home/release for libhugetlbfs.
The libhugetlbfs test suite is somewhat strange in that I suspect it started
as testing for libhugetlbfs itself. When it was written, the thought may have
been that people would use libhugetlfs as the primary interface to hugetlb
pages. That is not the case today. Over time, hugetlbfs tests not associated
with libhugetlbfs were added.
If we want to migrate libhugetlbfs tests, then I think we would only want to
migrate the non-libhugetlbfs test cases. Although, the libhugetlbfs specific
tests are useful as they 'could' point out regressions.
Added Eric (libhugetlbfs maintainer) on Cc for another opinion.
>
> [1] https://github.com/libhugetlbfs/libhugetlbfs/tree/master/tests
>
--
Mike Kravetz
Powered by blists - more mailing lists