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]
Message-ID: <AANLkTintYZ00-MZD5hv7p0zNeDJTyyzdR-C=7qWo78Ly@mail.gmail.com>
Date:	Wed, 23 Feb 2011 14:17:34 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Tejun Heo <tj@...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 1:03 PM, Tejun Heo <tj@...nel.org> wrote:
>> > 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.
>>
>> it will reuse previous not used entries in the init_memory_mapping().
>
> Hmmm... I'm not really following.  Can you elaborate?  The reason why
> smaller mapping is bad is because of increased TLB pressure.  What
> does using the existing entries have to do with it?

assume 1g page is used. first node will actually mapped 512G already.
so if the system only have 1024g. then first 512g page table will on node0 ram.
second 512g page table will be on node4.

when only 2M are used, it is 1G boundary. for 1024g system.
page table (about 512k) for mem 0-128g is on node0.
page table (about 512k) for mem 128g-256g is on node1.
...
Do you mean we need to put those all 512k together to reduce TLB presure?

Yinghai
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ