t and pmd_alloc to inline calls to simplify the
main code
removed printing of the huge page size in mm/hugetlb.c since this
information is already
available in /proc/meminfo and leaves the remaining changes all
powerpc specific
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
d
nothing or an invalid choice is specified.
Tested 64K huge pages successfully with the libhugetlbfs 1.2.
Changes from v2:
Moved functions from header file into hugetlbpage.c where they are used.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
diff --git a/Documentation/
Arnd Bergmann wrote:
> We started discussing this in v1, but the discussion got sidetracked:
> Is there a technical reason why you don't also allow 1M pages, which
> may be useful in certain scenarios?
>
No, it was mostly a matter of the time I have had and machines easily
available to me for te
release with its 'make func' and 'make stress' test
invocations.
This patch requires the patch posted by Mel Gorman that adds
HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
lacking hugepage support" on 2007-11-15.
Signed-off-by: J
to fit in one base page. This patch would have to be applied
after part 1.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
hugetlbpage.c | 53 ++---
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/powe
David Gibson wrote:
> On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
>
>> This patch adds reliability to the 64K huge page option by making use of
>> the PMD for 64K huge pages when base pages are 4k. So instead of a 12
>> bit pte it would be 7 bit
Paul Mackerras wrote:
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
>
A couple of hunks fail in this file when applying to the current tree.
...
> diff --git a/include/asm-powerpc/mmu-hash64.h
> b/include/asm-powerpc/mmu-hash64.h
> index 695962f..053f86b 100644
> --- a/include/a
.
A BUG_ON in huge_add_hstate is commented out in order to allow 64K huge
pages to continue to work on power.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
include/linux/hugetlb.h | 10 ++
mm/hugetlb.c| 15 ++-
2 files changed, 16 insertions(+),
The 16G page locations have been saved during early boot in an array.
The alloc_bm_huge_page() function adds a page from here to the
huge_boot_pages list.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 22 ++
1 file chang
The 16G huge pages have to be reserved in the HMC prior to boot. The
location of the pages are placed in the device tree. This patch adds
code to scan the device tree during very early boot and save these page
locations until hugetlbfs is ready for them.
Signed-off-by: Jon Tollefson <[EM
that it is not shifted to 0. Otherwise it
would create an infinite loop when the shift value is for a 16G page
(when base page size is 64K).
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 62 ++
include/asm-p
didn't seem to generate an
EOVERFLOW in my test case.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
fs/compat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/compat.c b/fs/compat.c
index 2ce4456..6eb6aad 100644
--- a/fs/compat.c
+++ b/fs/compat.
igned-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c |9 -
arch/powerpc/mm/hugetlbpage.c| 267 +--
arch/powerpc/mm/init_64.c|8 -
arch/powerpc/mm/tlb_64.c |2
include/asm-powerpc/mmu-hash
This patch set builds on Nick Piggin's patches for multi size and giant
hugetlb page support of April 22. The following set of patches adds
support for 16G huge pages on ppc64 and support for multiple huge page
sizes at the same time on ppc64. Thus allowing 64K, 16M, and 16G huge
pages given
Nick Piggin wrote:
> On Tue, May 13, 2008 at 12:25:27PM -0500, Jon Tollefson wrote:
>
>> Instead of using the variable mmu_huge_psize to keep track of the huge
>> page size we use an array of MMU_PAGE_* values. For each supported
>> huge page size we need to know the
This patch set builds on Andi Kleen's patches for GB pages for hugetlb
posted on March 16th. This set adds support for 16G huge pages on
ppc64. Supporting multiple huge page sizes on ppc64 as defined in
Andi's patches is not a part of this set; that will be included in a
future patch.
The first
Allow alloc_bm_huge_page() to be overridden by architectures that can't always
use bootmem.
This requires huge_boot_pages to be available for use by this function. Also
huge_page_size()
and other functions need to use a long so that they can handle the 16G page
size.
Signed-off-by
The 16G page locations have been saved during early boot in an array. The
alloc_bm_huge_page() function adds a page from here to the huge_boot_pages list.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
hugetlbpage.c | 19 +++
1 file changed, 19 insertions(+)
The 16G huge pages have to be reserved in the HMC prior to boot. The location
of
the pages are placed in the device tree. During very early boot these
locations are
saved for use by hugetlbfs.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c
The huge page size is setup for 16G pages if that size is specified at
boot-time. The support for
multiple huge page sizes is not being utilized yet. That will be in a future
patch.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
hugetlbpage.c | 12 ++--
1 file chang
David Gibson wrote:
> On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Could people take one last look at these patches and if there are no
>> issues, please send Ack-bys to Andrew who will push them to Linus for
>> 2.6.27.
>>
>> [PATCH 1/6 v2] allow arch spec
Just tried to build the latest version from Linus' tree and I am getting
a link error.
building with the pseries_defconfig
...
LD drivers/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: modpost: Found 6 section mismatch(es).
To see full details build your kernel with:
'make CONF
Segher Boessenkool wrote:
My previous patch to fix compilation with binutils-2.17 causes
a "file truncated" build error from ld with binutils 2.15 (and
possibly older), and a warning with 2.16 and 2.17.
This fixes it.
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
---
arch/powerpc/kerne
David Gibson wrote:
> When BenH and I were looking at the new code for handling 16G pages,
> we noticed a small bug. It doesn't actually break anything user
> visible, but it's certainly not the way things are supposed to be.
> The 16G patches didn't update the huge_pte_offset() and
> huge_pte_all
Benjamin Herrenschmidt wrote:
>> Actually, Jon has been hitting an occasional pagetable lock related
>> problem. The last theory was that it might be some sort of race but it's
>> vaguely possible that this is the issue. Jon?
>>
>
> All hugetlbfs ops should be covered by the big PTL except wal
Benjamin Herrenschmidt wrote:
> On Tue, 2008-09-02 at 17:16 -0500, Jon Tollefson wrote:
>
>> Benjamin Herrenschmidt wrote:
>>
>>>> Actually, Jon has been hitting an occasional pagetable lock related
>>>> problem. The last theory was that it might
David Gibson wrote:
> On Tue, Sep 02, 2008 at 12:12:27PM -0500, Jon Tollefson wrote:
>
>> David Gibson wrote:
>>
>>> When BenH and I were looking at the new code for handling 16G pages,
>>> we noticed a small bug. It doesn't actually break anything
Jon Tollefson wrote:
> David Gibson wrote:
>
>> On Tue, Sep 02, 2008 at 12:12:27PM -0500, Jon Tollefson wrote:
>>
>>
>>> David Gibson wrote:
>>>
>>>
>>>> When BenH and I were looking at the new code for handli
justs the size and gets the next active region containing it.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/numa.c | 63 -
include/linux/mm.h |2 +
mm/page_alloc.c| 19 ++
3 files
Adam Litke wrote:
> This seems like the right approach to me. I have pointed out a few
> stylistic issues below.
>
Thanks. I'll make those changes. I assume by __mminit you meant __meminit
Jon
> On Tue, 2008-09-30 at 09:53 -0500, Jon Tollefson wrote:
>
>
&
Kumar Gala wrote:
> Out of interest how to do you guys represent NUMA regions of memory in
> the device tree?
>
> - k
Looking at the source code in numa.c I see at the start of
do_init_bootmem() that parse_numa_properties() is called. It appears to
be looking at memory nodes and getting the node i
Kumar Gala wrote:
>
> On Oct 6, 2008, at 10:42 AM, Jon Tollefson wrote:
>
>> Kumar Gala wrote:
>>> Out of interest how to do you guys represent NUMA regions of memory in
>>> the device tree?
>>>
>>> - k
>> Looking at the source code
justs the size and gets the next active region containing it.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
Changes:
-style changes as suggested by Adam Litke
Please consider for 2.6.28.
arch/powerpc/mm/numa.c | 63 -
include
s the size and gets the next active region containing it.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
Changes:
v2:
-style changes as suggested by Adam Litke
v3:
-moved helper function to powerpc code since it is the only user at
present
-m
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-09 at 15:18 -0500, Jon Tollefson wrote:
If there are multiple reserved memory blocks via lmb_reserve() that are
contiguous addresses and on different NUMA nodes we are losing track of which
address ranges to reserve in bootmem on which node. I
If mem= is used on the boot command line to limit memory then the memory block
where a 16G page resides may not be available.
Thanks to Michael Ellerman for finding the problem.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c |6 --
1 file c
Please consider the following patches for the 2.6.27 stable tree.
The first two allow a powerpc machine with more then 2 numa nodes
to boot when 16G pages are enabled. The third one allows a powerpc
machine to boot if using 16G pages and the mem= boot param.
thanks,
Jon
powerpc: Reserve in boo
It was suggested by Andrew that using a macro that made an array
look like a function call made it harder to understand the code.
Cleaned up use of macro. We now reference the pgtable_cache array
directly instead of using a macro.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
Cc
Dave Hansen wrote:
I got a bug report about a distro kernel not booting on a particular
machine. It would freeze during boot:
...
Could not find start_pfn for node 1
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 123783
Policy zone: DMA
Kernel com
Paul Mackerras wrote:
Dave Hansen writes:
This patch ensures that we do not touch bootmem for any node which
has not been initialized.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
So, should I be sending this to Linus for 2.6.28?
I notice you have added a dbg() call. For a 2.6.28
40 matches
Mail list logo
