Fix hugetlb pool allocation with empty nodes

It didnt take long to realise that alloc_fresh_huge_page is allocating from node 7 without GFP_THISNODE set, so we fallback to its next preferred node (ie 1). This means we end up with a 1/3 2/3 imbalance.

After fixing this it still didnt work, and after some more poking I see why. When building our fallback zonelist in build_zonelists_node we skip empty zones. This means zone 7 never registers node 7's empty zonelists and instead registers node 1's. Therefore when we ask for a page from node 7, using the GFP_THISNODE flag we end up with node 1 memory.

By removing the populated_zone() check in build_zonelists_node we fix the problem:

Im guessing registering empty remote zones might make the SGI guys a bit unhappy, maybe we should just force the registration of empty local zones? Does anyone care?

Quoted 3 lines

Im guessing registering empty remote zones might make the SGI guys a bit unhappy, maybe we should just force the registration of empty local zones? Does anyone care?

Why would that make us unhappy?

Quoted 1 line

Why would that make us unhappy?

Since SGI boxes can have lots of NUMA nodes I was worried the patch might negatively affect you. It sounds like thats not so much of an issue.

Im guessing registering empty remote zones might make the SGI guys a bit unhappy, maybe we should just force the registration of empty local zones? Does anyone care?

Quoted 3 lines

Im guessing registering empty remote zones might make the SGI guys a bit unhappy, maybe we should just force the registration of empty local zones? Does anyone care?

I care. Don't do that please. Empty nodes cause all kinds of problems.

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

Quoted 8 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

I think we need something like for_each_online_node for each node with memory otherwise we are going to replicate this all over the place for memoryless nodes. Add a nodemap for populated nodes?

I.e.

for_each_mem_node?

Then you do not have to check the zone flags all the time. May avoid a lot of mess?

Quoted 8 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

I think we need something like for_each_online_node for each node with memory otherwise we are going to replicate this all over the place for memoryless nodes. Add a nodemap for populated nodes?

I.e.

for_each_mem_node?

Then you do not have to check the zone flags all the time. May avoid a lot of mess?

From a performance point of view, I don't think using the zone flags to

Quoted 8 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

I think we need something like for_each_online_node for each node with memory otherwise we are going to replicate this all over the place for memoryless nodes. Add a nodemap for populated nodes?

I.e.

for_each_mem_node?

Then you do not have to check the zone flags all the time. May avoid a lot of mess?

* int node_possible(node) Is some node possible?
+ * int node_populated(node) Is some node populated [at 'HIGHUSER]
*

mm/hugetlb.c static int alloc_fresh_huge_page(void) · line 123

Quoted 5 lines · Lee Schermerhorn

mm/hugetlb.c +5 -0

+  					HUGETLB_PAGE_ORDER);
+
+		nid = next_node(nid, node_online_map);
+		if (nid == MAX_NUMNODES)
+			nid = first_node(node_online_map);

Maybe use nr_node_ids here? May save some scanning over online maps?

Quoted 4 lines

* int node_possible(node) Is some node possible?
+ * int node_populated(node) Is some node populated [at 'HIGHUSER]
*

Good.

Quoted 8 lines · Christoph Lameter

Quoted 5 lines · Lee Schermerhorn

mm/hugetlb.c +5 -0

+                                   HUGETLB_PAGE_ORDER);
+
+           nid = next_node(nid, node_online_map);
+           if (nid == MAX_NUMNODES)
+                   nid = first_node(node_online_map);

Quoted 1 line

Maybe use nr_node_ids here? May save some scanning over online maps?

Good idea. I won't get to it until next week. Maybe we'll have more comments by then.

Anton: anything to add?

Quoted 14 lines · Lee Schermerhorn

Quoted 9 lines · Christoph Lameter

mm/hugetlb.c static int alloc_fresh_huge_page(void) · line 123

Quoted 5 lines · Lee Schermerhorn

mm/hugetlb.c +5 -0

+                                   HUGETLB_PAGE_ORDER);
+
+           nid = next_node(nid, node_online_map);
+           if (nid == MAX_NUMNODES)
+                   nid = first_node(node_online_map);

Maybe use nr_node_ids here? May save some scanning over online maps?

Good idea. I won't get to it until next week. Maybe we'll have more comments by then.

Quoted 1 line

Anton: anything to add?

Actually, I was going to ask? Why don't we just iterate over node_populated_map? You've exported it and everything... Rather than going over some other map and then checking to see if the node is populated every time?

Quoted 15 lines · Christoph Lameter

Quoted 8 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

I think we need something like for_each_online_node for each node with memory otherwise we are going to replicate this all over the place for memoryless nodes. Add a nodemap for populated nodes?

Quoted 6 lines

I.e.

for_each_mem_node?

Then you do not have to check the zone flags all the time. May avoid a lot of mess?

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

I don't think that a 'for_each_*_node()' macro is appropriate for this usage, as allocate_fresh_huge_page() is an "incremental allocator" that returns a page from the "next eligible node" on each call.

By the way: does anything protect the "static int nid" in allocate_fresh_huge_page() from racing attempts to set nr_hugepages? Can this happen? Do we care?

mm/hugetlb.c +0 -2

-       page = alloc_pages_node(nid, htlb_alloc_mask|__GFP_COMP|__GFP_NOWARN,
-                                       HUGETLB_PAGE_ORDER);

Index: Linux/include/linux/nodemask.h

+ * node_set_poplated(node) set bit 'node' in node_populated_map
+ * node_not_poplated(node) clear bit 'node' in node_populated_map

[Adding wli to the Cc]

Quoted 7 lines · Lee Schermerhorn

Quoted 6 lines · Christoph Lameter

Quoted 4 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Quoted 10 lines

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

For libhugetlbfs purposes, with 1.1 and later, we've recommended folks use numactl in coordination with the library to specify the policy. After a kernel fix that submitted a while back (and has been merged for at least a few releases), hugepages interleave properly when requested.

Quoted 4 lines

By the way: does anything protect the "static int nid" in allocate_fresh_huge_page() from racing attempts to set nr_hugepages? Can this happen? Do we care?

Hrm, not sure if we care or not.

We've got a draft of patch that exports nr_hugepages on a per-node basis in sysfs. Will post it soon, as an additional, more flexible interface for dealing with hugepages on NUMA.

<snip>

mm/hugetlb.c static int alloc_fresh_huge_page(void) · line 111

Quoted 2 lines

mm/hugetlb.c +0 -2

-       page = alloc_pages_node(nid, htlb_alloc_mask|__GFP_COMP|__GFP_NOWARN,
-                                       HUGETLB_PAGE_ORDER);

<snip>

mm/hugetlb.c static int alloc_fresh_huge_page(void) · line 119

Quoted 3 lines

mm/hugetlb.c +3 -0

+                       page = alloc_pages_node(nid,
+                                       GFP_HIGHUSER|__GFP_COMP|GFP_THISNODE,
+                                       HUGETLB_PAGE_ORDER);

Are we taking out the GFP_NOWARN for a reason? I noticed this in Anton's patch, but forgot to ask.

<snip>

Quoted 1 line

Index: Linux/include/linux/nodemask.h

<snip>

Quoted 2 lines

+ * node_set_poplated(node) set bit 'node' in node_populated_map
+ * node_not_poplated(node) clear bit 'node' in node_populated_map

typos? (poplated v. populated)

<snip>

Looks reasonable otherwise.

Thanks,
Nish

Quoted 7 lines

mm/hugetlb.c static int alloc_fresh_huge_page(void) · line 119

Quoted 4 lines

mm/hugetlb.c +3 -0

+                       page = alloc_pages_node(nid,
+                                       GFP_HIGHUSER|__GFP_COMP|GFP_THISNODE,
+                                       HUGETLB_PAGE_ORDER);

Are we taking out the GFP_NOWARN for a reason? I noticed this in Anton's patch, but forgot to ask.

Actually, I hadn't noticed, but a quick look shows that GFP_THISNODE contains the __GFP_NOWARN flag, as well as '_NORETRY which I think is OK/desirable.

Quoted 10 lines · Nish Aravamudan

[Adding wli to the Cc]

Quoted 7 lines · Lee Schermerhorn

Quoted 6 lines · Christoph Lameter

Quoted 4 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

<snip>

Quoted 5 lines

Quoted 5 lines

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Quoted 5 lines

Quoted 5 lines

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

Quoted 5 lines

For libhugetlbfs purposes, with 1.1 and later, we've recommended folks use numactl in coordination with the library to specify the policy. After a kernel fix that submitted a while back (and has been merged for at least a few releases), hugepages interleave properly when requested.

You mean using numactl command to preposition a hugetlb shmem seg external to the application? That's one way to do it. Some apps like to handle this internally themselves.

Quoted 5 lines

Quoted 3 lines

By the way: does anything protect the "static int nid" in allocate_fresh_huge_page() from racing attempts to set nr_hugepages? Can this happen? Do we care?

Hrm, not sure if we care or not.

Shouldn't happen too often, I think. And the only result should be some additional imbalance that this patch is trying to address. Still, I don't know that it's worth another lock. And, I don't think we want to hold the hugetlb_lock over the page allocation. However, with a slight reordering of the code, with maybe an additional temporary nid variable, we could grab the hugetlb lock while updating the static nid each time around the loop. I don't see this as a performance path, but again, is it worth it?

Quoted 3 lines

We've got a draft of patch that exports nr_hugepages on a per-node basis in sysfs. Will post it soon, as an additional, more flexible interface for dealing with hugepages on NUMA.

You mean the ability to specify explicitly the number of hugepages per node?

Quoted 11 lines

<snip>

Quoted 2 lines

mm/hugetlb.c +0 -2

-       page = alloc_pages_node(nid, htlb_alloc_mask|__GFP_COMP|__GFP_NOWARN,
-                                       HUGETLB_PAGE_ORDER);

<snip>

Quoted 3 lines

mm/hugetlb.c +3 -0

+                       page = alloc_pages_node(nid,
+                                       GFP_HIGHUSER|__GFP_COMP|GFP_THISNODE,
+                                       HUGETLB_PAGE_ORDER);

Quoted 2 lines

Are we taking out the GFP_NOWARN for a reason? I noticed this in Anton's patch, but forgot to ask.

Actually, I hadn't noticed, but a quick look shows that GFP_THISNODE contains the __GFP_NOWARN flag, as well as '_NORETRY which I think is OK/desirable.

Quoted 2 lines · Lee Schermerhorn

Quoted 1 line · Nish Aravamudan

[Adding wli to the Cc]

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

Hrm, I forgot to reply to that bit before. I think hugetlbfs mappings will obey at least the interleave policy, per:

struct zonelist *huge_zonelist(struct vm_area_struct *vma, unsigned long addr)

{
        struct mempolicy *pol = get_vma_policy(current, vma, addr);

        if (pol->policy == MPOL_INTERLEAVE) {
                unsigned nid;

                nid = interleave_nid(pol, vma, addr, HPAGE_SHIFT);
                return NODE_DATA(nid)->node_zonelists + gfp_zone(GFP_HIGHUSER);
        }
        return zonelist_policy(GFP_HIGHUSER, pol);
}

From one task, mbind the segment with, say, interleave policy, but don't

Quoted 10 lines

Quoted 6 lines

For libhugetlbfs purposes, with 1.1 and later, we've recommended folks use numactl in coordination with the library to specify the policy. After a kernel fix that submitted a while back (and has been merged for at least a few releases), hugepages interleave properly when requested.

You mean using numactl command to preposition a hugetlb shmem seg external to the application? That's one way to do it. Some apps like to handle this internally themselves.

Hrm, well, libhugetlbfs does not do anything with shmem segs -- I was referring to use numactl to set the policy for hugepages which then our malloc implementation takes advantage of. Hugepages show up interleaved across the nodes. This was what required a simple mempolicy fix last August (3b98b087fc2daab67518d2baa8aef19a6ad82723)

Quoted 3 lines · Nish Aravamudan

Quoted 2 lines · Lee Schermerhorn

Quoted 1 line · Nish Aravamudan

[Adding wli to the Cc]

<snip>

Quoted 15 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

Hrm, I forgot to reply to that bit before. I think hugetlbfs mappings will obey at least the interleave policy, per:

struct zonelist *huge_zonelist(struct vm_area_struct *vma, unsigned long addr)

Quoted 11 lines

{
        struct mempolicy *pol = get_vma_policy(current, vma, addr);

        if (pol->policy == MPOL_INTERLEAVE) {
                unsigned nid;

                nid = interleave_nid(pol, vma, addr, HPAGE_SHIFT);
                return NODE_DATA(nid)->node_zonelists + gfp_zone(GFP_HIGHUSER);
        }
        return zonelist_policy(GFP_HIGHUSER, pol);
}

I should have been more specific. I've only used hugetlbfs with shmem segments. I haven't tried libhugetlbfs [does it work on ia64, yet?]. Huge page shmem segments don't set/get the shared policy on the shared object itself. Rather they use the task private vma_policy.

Huge tlb shared segments would obey shared policy if the hugetlb_vm_ops were hooked up to the shared policy mechanism, but they are not. So, there is no way to set the shared policy on such segments. I tried a simple patch to add the shmem_{get|set}_policy() functions to the hugetlb_vm_ops, and this almost works. However, a cat
of /proc/<pid>/numa_maps hangs. Haven't investigated the hang, yet.

Quoted 15 lines · Christoph Lameter

Quoted 8 lines · Lee Schermerhorn

Quoted 3 lines · Anton Blanchard

An interesting bug was pointed out to me where we failed to allocate hugepages evenly. In the example below node 7 has no memory (it only has CPUs). Node 0 and 1 have plenty of free memory. After doing:

Here's my attempt to fix the problem [I see it on HP platforms as well], without removing the population check in build_zonelists_node(). Seems to work.

I think we need something like for_each_online_node for each node with memory otherwise we are going to replicate this all over the place for memoryless nodes. Add a nodemap for populated nodes?

Quoted 6 lines

I.e.

for_each_mem_node?

Then you do not have to check the zone flags all the time. May avoid a lot of mess?

OK, here's a rework that exports a node_populated_map and associated access functions from page_alloc.c where we already check for populated zones. Maybe this should be "node_hugepages_map" ?

Also, we might consider exporting this to user space for applications that want to "interleave across all nodes with hugepages"--not that hugetlbfs mappings currently obey "vma policy". Could still be used with the "set task policy before allocating region" method [not that I advocate this method ;-)].

I don't think that a 'for_each_*_node()' macro is appropriate for this usage, as allocate_fresh_huge_page() is an "incremental allocator" that returns a page from the "next eligible node" on each call.

By the way: does anything protect the "static int nid" in allocate_fresh_huge_page() from racing attempts to set nr_hugepages? Can this happen? Do we care?

Again, I chose to rework Anton's original patch, maintaining his rationale/discussion, rather create a separate patch. Note the "Rework" comments therein--especially regarding NORMAL zone. I expect we'll need a few more rounds of "discussion" on this issue. And, it'll require rework to merge with the "change zonelist order" series that hits the same area.

Lee

[PATCH] Fix hugetlb pool allocation with empty nodes - V3

mm/page_alloc.c 2007-05-09 11:16:27.000000000 -0400 renamed from mm/page_alloc.c 2007-05-08 11:47:45.000000000 -0400 +0 -0

mm/page_alloc.c 2007-05-09 11:16:27.000000000 -0400 renamed from mm/page_alloc.c 2007-05-08 11:47:45.000000000 -0400 +4 -1

@@ -2021,11 +2024,14 @@ void show_free_areas(void)
  * Builds allocation fallback zone lists.
  *
  * Add all populated zones of a node to the zonelist.
+ * Record nodes with populated gfp_zone(GFP_HIGHUSER) for huge page allocation.
  */
 static int __meminit build_zonelists_node(pg_data_t *pgdat,
-                       struct zonelist *zonelist, int nr_zones, enum zone_type zone_type)
+                       struct zonelist *zonelist, int nr_zones,
+                       enum zone_type zone_type)
 {
        struct zone *zone;
+       enum zone_type zone_highuser = gfp_zone(GFP_HIGHUSER);
 
        BUG_ON(zone_type >= MAX_NR_ZONES);
        zone_type++;

@@ -2036,7 +2042,10 @@ static int __meminit build_zonelists_nod
                if (populated_zone(zone)) {

This completely breaks hugepage allocation on 4-node x86_64 box I have here. Each node has <4GB of memory, so all memory is ZONE_DMA and ZONE_DMA32. gfp_zone(GFP_HIGHUSER) is ZONE_NORMAL, though. So all nodes are not populated by the default initialization to an empty nodemask.

Thanks to Andy Whitcroft for helping me debug this.

I'm not sure how to fix this -- but I ran into while trying to base my sysfs hugepage allocation patches on top of yours.

Thoughts?

This completely breaks hugepage allocation on 4-node x86_64 box I have here. Each node has <4GB of memory, so all memory is ZONE_DMA and ZONE_DMA32. gfp_zone(GFP_HIGHUSER) is ZONE_NORMAL, though. So all nodes are not populated by the default initialization to an empty nodemask.

Thanks to Andy Whitcroft for helping me debug this.

I'm not sure how to fix this -- but I ran into while trying to base my sysfs hugepage allocation patches on top of yours.

On Wed, 2007-05-16 at 12:59 -0700, Nish Aravamudan wrote:

<snip>

Quoted 11 lines

This completely breaks hugepage allocation on 4-node x86_64 box I have here. Each node has <4GB of memory, so all memory is ZONE_DMA and ZONE_DMA32. gfp_zone(GFP_HIGHUSER) is ZONE_NORMAL, though. So all nodes are not populated by the default initialization to an empty nodemask.

Thanks to Andy Whitcroft for helping me debug this.

I'm not sure how to fix this -- but I ran into while trying to base my sysfs hugepage allocation patches on top of yours.

OK. Try this. Tested OK on 4 node [+ 1 pseudo node] ia64 and 2 node x86_64. The x86_64 had 2G per node--all DMA32.

Notes:

1) applies on 2.6.22-rc1-mm1 atop my earlier patch to add the call to check_highest_zone() to build_zonelists_in_zone_order(). I think it'll apply [with offsets] w/o that patch.

Quoted 20 lines · Lee Schermerhorn

On Wed, 2007-05-16 at 12:59 -0700, Nish Aravamudan wrote:

<snip>

Quoted 11 lines

This completely breaks hugepage allocation on 4-node x86_64 box I have here. Each node has <4GB of memory, so all memory is ZONE_DMA and ZONE_DMA32. gfp_zone(GFP_HIGHUSER) is ZONE_NORMAL, though. So all nodes are not populated by the default initialization to an empty nodemask.

Thanks to Andy Whitcroft for helping me debug this.

I'm not sure how to fix this -- but I ran into while trying to base my sysfs hugepage allocation patches on top of yours.

OK. Try this. Tested OK on 4 node [+ 1 pseudo node] ia64 and 2 node x86_64. The x86_64 had 2G per node--all DMA32.

Notes:

Quoted 3 lines

1) applies on 2.6.22-rc1-mm1 atop my earlier patch to add the call to check_highest_zone() to build_zonelists_in_zone_order(). I think it'll apply [with offsets] w/o that patch.

Could you give both patches (or just this one) against 2.6.22-rc1 or current -linus? -mm1 has build issues on ppc64 and i386 (as reported by Andy and Mel in other threads).

Quoted 25 lines · Nish Aravamudan

Quoted 23 lines · Lee Schermerhorn

On Wed, 2007-05-16 at 12:59 -0700, Nish Aravamudan wrote:

<snip>

Quoted 11 lines

This completely breaks hugepage allocation on 4-node x86_64 box I have here. Each node has <4GB of memory, so all memory is ZONE_DMA and ZONE_DMA32. gfp_zone(GFP_HIGHUSER) is ZONE_NORMAL, though. So all nodes are not populated by the default initialization to an empty nodemask.

Thanks to Andy Whitcroft for helping me debug this.

I'm not sure how to fix this -- but I ran into while trying to base my sysfs hugepage allocation patches on top of yours.

OK. Try this. Tested OK on 4 node [+ 1 pseudo node] ia64 and 2 node x86_64. The x86_64 had 2G per node--all DMA32.

Notes:

1) applies on 2.6.22-rc1-mm1 atop my earlier patch to add the call to check_highest_zone() to build_zonelists_in_zone_order(). I think it'll apply [with offsets] w/o that patch.

Quoted 3 lines

Could you give both patches (or just this one) against 2.6.22-rc1 or current -linus? -mm1 has build issues on ppc64 and i386 (as reported by Andy and Mel in other threads).

Nish:

Here's the hugepage fix against 2.6.22-rc2 for your testing. I think the patch still needs to cook in -mm if you think it's OK.