linux-kernel - Re: questions about 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:	Wed, 23 Feb 2011 21:46:56 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	x86@...nel.org, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: questions about init_memory_mapping_high()

On Wed, Feb 23, 2011 at 12:24:58PM -0800, Yinghai Lu wrote:
> >    I guess this was the reason why the commit message showed usage of
> >    2MiB mappings so that each node would end up with their own third
> >    level page tables.  Is this something we need to optimize for?  I
> >    don't recall seeing recent machines which don't use 1GiB pages for
> >    the linear mapping.  Are there NUMA machines which can't use 1GiB
> >    mappings?
> 
> till now:
> amd 64 cpu does support 1gb page.
> 
> Intel CPU Nehalem-EX does not. and several vendors do provide 8 sockets
> NUMA system with 1024g and 2048g RAM

That's interesting.  Didn't expect that.  So, this one is an actually
valid reason for implementing per node mapping.  Is this Nehalem-EX
only thing?  Or is it applicable to all xeons upto now?

> > 3. The new code creates linear mapping only for memory regions where
> >    e820 actually says there is memory as opposed to mapping from base
> >    to top.  Again, I'm not sure what the intention of this change was.
> >    Having larger mappings over holes is much cheaper than having to
> >    break down the mappings into smaller sized mappings around the
> >    holes both in terms of memory and run time overhead.  Why would we
> >    want to match the linear address mapping to the e820 map exactly?
> 
> we don't need to map those holes if there is any.

Yeah, sure, my point was that not mapping those holes is likely to be
worse.  Wouldn't it be better to get low and high ends of the occupied
area and expand those to larger mapping size?  It's worse to match the
memory map exactly.  You unnecessarily end up with smaller mappings.

> for hotplug case, they should map new added memory later.

Sure.

> > Also, Yinghai, can you please try to write commit descriptions with
> > more details?  It really sucks for other people when they have to
> > guess what the actual changes and underlying intentions are.  The
> > commit adding init_memory_mapping_high() is very anemic on details
> > about how the behavior changes and the only intention given there is
> > RED-PEN removal even which is largely a miss.
> 
> i don't know what you are talking about. that changelog is clear enough.

Ah well, if you still think the changelog is clear enough, I give up.
I guess I'll just keep rewriting your changelogs.

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/