linux-kernel - Re: [PATCH 2/2] x86,mm,64bit: Round up memory boundary for init_memory_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Feb 2011 09:57:37 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/