THe shmoverride tests also fail with overcommit pages allocated, this
patch saves their value and then restores it when the test is finished.
Signed-off-by: Eric B Munson <[EMAIL PROTECTED]>
---
tests/shmoverride_unlinked.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --g
Some of the test suite will fail unexpectedly when the overcommit pool has
any pages allocated. This patch introduces a simple method for saving and
restoring the size of the overcommit pool so these tests can 0 it before
running.
Signed-off-by: Eric B Munson <[EMAIL PROTECTED]>
---
hugeutils.c
Having overcommit pages makes the heap-overflow test fail, this patch
uses the function introduces earlier to set the overcommit pool to 0.
This forces this test to be run as root only.
Signed-off-by: Eric B Munson <[EMAIL PROTECTED]>
---
tests/heap-overflow.c | 16 +++-
1 files cha
Eric B Munson wrote:
> Some of the test suite will fail unexpectedly when the overcommit pool has
> any pages allocated. This patch introduces a simple method for saving and
> restoring the size of the overcommit pool so these tests can 0 it before
> running.
>
> Signed-off-by: Eric B Munson <[EMA
The get_huge_pages() API is a close-to-kernel interface for the direct
allocation of hugepages. This forces the caller to deal with alignment and
fallback to base pages where suitable. For the casual user of hugepages
that does not care for such things, this patch adds get_hugepage_region().
It all
There has been some disagreement on what the exact purpose of get_huge_pages()
is. It was felt that the interface name implied that it dealt strictly with
hugepages. This was reinforced by the fact in 2.0 that the length parameter
had to be hugepage-aligned and that in 2.1-preX allocations were all
In the situation a caller allocates multiple buffers with
get_hugepage_region(), all the buffers will align to the start of the
hugepage. This means the buffers are almost certainly using the same
cachelines and operations like copying between the arrays will be mysteriously
slow in comparison to b
It has been asserted that the name get_huge_pages() implies the API is
a close-to-kernel interface for allocating hugepages and nothing else.
In 2.1-preX, this definition does not fit as it allows fallback to base pages
for example. This patch enforces the meaning implied by the function name by
r
On Fri, Nov 07, 2008 at 09:08:14AM +1100, David Gibson wrote:
> On Thu, Nov 06, 2008 at 11:19:18AM -0600, Adam Litke wrote:
> > On Thu, 2008-11-06 at 16:20 +, Mel Gorman wrote:
> > > +.SH NAME
> > > +hugetlbfs_unlinked_fd, hugetlbfs_unlinked_fd_for_size \- Open an
> > > unlinked file on a huge
On Fri, Nov 07, 2008 at 11:22:05AM +1100, David Gibson wrote:
> On Thu, Nov 06, 2008 at 10:49:35AM +, Mel Gorman wrote:
> > On Thu, Nov 06, 2008 at 12:06:23PM +1100, David Gibson wrote:
> > > On Thu, Nov 06, 2008 at 12:51:54AM +, Mel Gorman wrote:
> > > > On Thu, Nov 06, 2008 at 10:15:54AM
Mel Gorman wrote:
> The get_huge_pages() API is a close-to-kernel interface for the direct
> allocation of hugepages. This forces the caller to deal with alignment and
> fallback to base pages where suitable. For the casual user of hugepages
> that does not care for such things, this patch adds get
Mel Gorman wrote:
> It has been asserted that the name get_huge_pages() implies the API is
> a close-to-kernel interface for allocating hugepages and nothing else.
> In 2.1-preX, this definition does not fit as it allows fallback to base pages
> for example. This patch enforces the meaning implied
Before doing any segment remapping, the function verify_segment_layout() does
some basic sanity checking to make sure the program segments are properly
aligned for the selected remapping mode. For segments that will be remapped,
we must be able to align the start down to an address congruent with
On Fri, 2008-11-07 at 16:09 +, Mel Gorman wrote:
> @@ -179,6 +180,45 @@ void free_huge_pages(void *ptr)
> fclose(fd);
> }
>
> +/*
> + * Offset the buffer using bytes wasted due to alignment to avoid using the
> + * same cache lines for the start of every buffer returned by
> + * get_hug
On Fri, 2008-11-07 at 16:09 +, Mel Gorman wrote:
> The get_huge_pages() API is a close-to-kernel interface for the direct
> allocation of hugepages. This forces the caller to deal with alignment and
> fallback to base pages where suitable. For the casual user of hugepages
> that does not care f
On Fri, 2008-11-07 at 16:09 +, Mel Gorman wrote:
> It has been asserted that the name get_huge_pages() implies the API is
> a close-to-kernel interface for allocating hugepages and nothing else.
> In 2.1-preX, this definition does not fit as it allows fallback to base pages
> for example. This
/proc/mounts is now used in addition to /proc/meminfo for detecting huge page
sizes. Override the contents of that file as well.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
tests/meminfo_nohuge.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/tests/meminfo_
17 matches
Mail list logo
