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