lkml.org 
[lkml]   [2011]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] x86,mm,64bit: Round up memory boundary for init_memory_mapping_high()
    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


    \
     
     \ /
      Last update: 2011-02-26 10:01    [W:5.984 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site