Re: [PATCH 2/2] x86,mm,64bit: Round up memory boundary forinit_memory_mapping_high()

[Tejun Heo]

On Fri, Feb 25, 2011 at 12:18:44PM -0800, Yinghai Lu wrote:
> >  Or better, can you please make that explicit?
> > It currently depends on memories being registered in ascending address
> > order, right?  The memblock code already is NUMA aware, I think it
> > would be far better to make the node affine part explicit.
> 
> yes, memblock is numa aware after memblock_x86_register_active_regions().
> and it rely on early_node_map[].
> 
> do you mean let init_memory_mapping to take node id like setup_node_bootmem?
> so find_early_table_space could take nodeid instead of tbl_end? 

Yeap.

> > @@ -550,8 +548,12 @@ static int __init numa_register_memblks(struct numa_meminfo *mi)
> >  			end = max(mi->blk[i].end, end);
> >  		}
> >  
> > -		if (start < end)
> > +		if (start < end) {
> > +			init_memory_mapping(
> > +			  ALIGN_DOWN_TO_MAX_MAP_SIZE_AND_CONVERT_TO_PFN(start),
> > +			  ALIGN_UP_SIMILARY_BUT_DONT_GO_OVER_MAX_PFN(end));
> >  			setup_node_bootmem(nid, start, end);
> > +		}
> will have problem with cross node conf. like 0-4g, 8-12g on node0, 4g-8g, 12g-16g on node1.

And how common are they?  This whole cruft is basically meaningless if
1GiB mapping is supported, IOW, basically on all AMD 64s and all
post-nehalem intels.  Why not just cite the limitation in the comment
and stick to something simple?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/