Re: [PATCH 2/4] hugetlb: fix pool allocation with empty nodes

[Nishanth Aravamudan <nacc@us.ibm.com>]

On 14.09.2007 [11:53:25 -0700], Christoph Lameter wrote:
> On Thu, 6 Sep 2007, Nishanth Aravamudan wrote:
> 
> >  	if (nid < 0)
> > -		nid = first_node(node_online_map);
> > +		nid = first_node(node_states[N_HIGH_MEMORY]);
> >  	start_nid = nid;
> 
> Can huge pages live in high memory? Otherwise I think we could use
> N_REGULAR_MEMORY here. There may be issues on 32 bit NUMA if we
> attempt to allocate memory from the highmem nodes.

hugepages are allocated with:

	htlb_alloc_mask|__GFP_COMP|__GFP_THISNODE|__GFP_NOWARN

where

	static gfp_t htlb_alloc_mask = GFP_HIGHUSER;

which, in turn, is:

	#define GFP_HIGHUSER \
	(__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)

So, yes, they can come from HIGHMEM, AFAICT. And I've tested this
patchset (at some point in the past admittedly) on NUMA-Q.

But I'm confused by your question altogether now. Looking at
2.6.23-rc8-mm2:

memoryless-nodes-introduce-mask-of-nodes-with-memory
(74a0f5ea5609629a07fd73d59bde255a56a57fa5):

A node has its bit in N_HIGH_MEMORY set if it has any memory regardless
of t type of memory.  If a node has memory then it has at least one zone
defined in its pgdat structure that is located in the pgdat itself.

And, indeed, if CONFIG_HIGHMEM is off, N_HIGH_MEMORY == N_NORMAL_MEMORY.

So I think I'm ok?

I'll make sure to test on 32-bit NUMA (well, if 2.6.23-rc8-mm2 works on
it, of course. Looks like -mm1 did and -mm2 is still pending.)

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>