| 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
| ||
|
Message-ID: <20110301182506.GB23527@mtj.dyndns.org> Date: Tue, 1 Mar 2011 19:25:06 +0100 From: Tejun Heo <tj@...nel.org> To: David Rientjes <rientjes@...gle.com> Cc: Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>, tglx@...utronix.de, "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org Subject: Re: [GIT PULL tip:x86/mm] Hey, David. On Tue, Mar 01, 2011 at 09:18:45AM -0800, David Rientjes wrote: > This is important because we want to ensure that the physical topoloy of > the machine is still represented in an emulated environment to > appropriately describe the expected latencies between the nodes. It also > allows users who are using numa=fake purely as a debugging tool to test > more interesting configurations and benchmark memory accesses between > emulated nodes as though they were real. Sure, definitely. > 10 20 20 30 10 20 20 30 10 20 20 30 10 20 20 30 > 20 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 > 30 20 20 10 30 20 20 10 30 20 20 10 30 20 20 10 > 10 20 20 30 10 20 20 30 10 20 20 30 10 20 20 30 > 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 > 20 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 > 30 20 20 10 30 20 20 10 30 20 20 10 30 20 20 10 > 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 > 20 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 > 30 20 20 10 30 20 20 10 30 20 20 10 30 20 20 10 > 10 20 20 30 10 20 20 30 10 20 20 30 10 20 20 30 > 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 > 20 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 > 30 20 20 10 30 20 20 10 30 20 20 10 30 20 20 10 > 10 20 20 30 10 20 20 30 10 20 20 30 10 20 20 30 > 20 10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 > > (And that is what we see with 2.6.37.) And this should have been the result. I've actually tested with fake original distance table including asymmetric distances. > However, x86/mm describes these distances differently: > > node0/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 20 > node1/distance:10 10 20 20 10 20 20 20 10 20 20 20 10 20 20 20 > node2/distance:10 20 10 20 10 20 20 20 10 20 20 20 10 20 20 20 > node3/distance:10 20 20 10 10 20 20 20 10 20 20 20 10 20 20 20 > node4/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 20 > node5/distance:10 20 20 20 10 10 20 20 10 20 20 20 10 20 20 20 > node6/distance:10 20 20 20 10 20 10 20 10 20 20 20 10 20 20 20 > node7/distance:10 20 20 20 10 20 20 10 10 20 20 20 10 20 20 20 > node8/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 20 > node9/distance:10 20 20 20 10 20 20 20 10 10 20 20 10 20 20 20 > node10/distance:10 20 20 20 10 20 20 20 10 20 10 20 10 20 20 20 > node11/distance:10 20 20 20 10 20 20 20 10 20 20 10 10 20 20 20 > node12/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 20 > node13/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 10 20 20 > node14/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 10 20 > node15/distance:10 20 20 20 10 20 20 20 10 20 20 20 10 20 20 10 > > It looks as though the emulation changes sitting in x86/mm have dropped > the SLIT and are merely describing the emulated nodes as either having > physical affinity or not. It looks like I missed something. I'll look into it first thing tomorrow. If you feel like looking into where it's going wrong, please go ahead. BTW, how did you insert the custom SLIT table? If it's some ACPI trick I can use here, do you care to share? 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/
Powered by blists - more mailing lists