[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2012 11:58:49 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Dave Young <hidave.darkstar@...il.com>,
Dave Young <dyoung@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] move vm tools from Documentation/vm/ to tools/
On Thu, 02 Feb 2012 15:32:55 +0800
Cong Wang <xiyou.wangcong@...il.com> wrote:
> On 02/02/2012 10:13 AM, Dave Young wrote:
> > On Thu, Feb 2, 2012 at 5:17 AM, Andrew Morton<akpm@...ux-foundation.org> wrote:
> >> On Wed, 1 Feb 2012 14:34:20 +0800
> >> Dave Young<dyoung@...hat.com> wrote:
> >>
> >>> tools/ is the better place for vm tools which are used by many people.
> >>> Moving them to tools also make them open to more users instead of hide in
> >>> Documentation folder.
> >>>
> >>
> >> It would be nice to covert these into simple pass/fail tests and
> >> promote them to tools/testing/selftests/.
> >
> > Andrew, I'm not clear about this, do you means to selftest
> > hugepage-mmap.c, hugepage-shm.c and map_hugetlb.c? I think slabinfo
> > and page-types should stay in tools/vm/. Can you explain a bit?
> >
>
> Hey,
>
> Check the comments in these files:
>
> /*
> * hugepage-mmap:
> *
> * Example of using huge page memory in a user application using the mmap
> * system call.
>
>
> /*
> * hugepage-shm:
> *
> * Example of using huge page memory in a user application using Sys V
> shared
> * memory system calls. In this example the app is requesting 256MB of
> * memory that is backed by huge pages. The application uses the flag
> * SHM_HUGETLB in the shmget system call to inform the kernel that it is
> * requesting huge pages.
>
>
> /*
> * Example of using hugepage memory in a user application using the mmap
> * system call with MAP_HUGETLB flag.
>
> All of them are examples, not tests, not tools, thus Documentation/ is
> the best place for them.
um, read the code? All three programs are exactly pass/fail selftests.
They are very simplistic selftests and perhaps one day we'll write more
sophisticated selftest code. If we were to do this then these files
over in tools/vm would become obsolete. So we should put these into
tools/testing/selftests/ on day one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists