Ben, fyi. Begin forwarded message: From: "Sodani, Avinash" <[email protected]<mailto:[email protected]>> Subject: Resolution to the two ANL issues with SNC4 Date: May 25, 2016 at 3:42:09 PM CDT To: "Kumaran, Kalyan" <[email protected]<mailto:[email protected]>>, "Harms, Kevin" <[email protected]<mailto:[email protected]>>, "Parker, Scott J." <[email protected]<mailto:[email protected]>> Cc: "Kleen, Andi" <[email protected]<mailto:[email protected]>>, "Chinthamani, Sundaram" <[email protected]<mailto:[email protected]>>, "Sodani, Avinash" <[email protected]<mailto:[email protected]>>, "Allison, CM" <[email protected]<mailto:[email protected]>>, "Kirkendall, Keith G" <[email protected]<mailto:[email protected]>>, "Chaffin, Benjamin C" <[email protected]<mailto:[email protected]>> Hi Kalyan, Here is the summary of the resolution to the two SNC4 issues that we were discussing in our meetings. The link to upstream OS patch is attached. Andi will provide any pointers to MPSP distributions as necessary. Thanks, -Avinash Issue 1: “Cluster 0/4” in SNC4 does not get full bandwidth even for local accesses. Memory NUMA Domain 4 5 6 7 CPU NUMA Domain 0 73,475.60 84,302.20 107,423.70 55,924.00 1 65,511.00 112,528.40 55,557.00 77,935.00 2 60,390.10 67,572.70 111,543.80 77,941.20 3 63,518.40 102,543.80 76,201.40 111622.4 Root Cause: OS puts idle threads in mwait. In SNC4, the addresses for these OS mwaits were being assigned such they all (288 of them, one per thread) were getting mapped into the tag directories in cluster 0. This was overwhelming the mechanism architected to handle mwait wakeup, causing significant slowdowns for the memory traffic getting routed through the tag directories in cluster 0. We don’t see this behavior for Quadrant and All-to-all modes because the mwait addresses are distributed to all tag directories, and therefore the mwait mechanisms do not get overwhelmed. Fix: OS patch has been released that distributes the OS mwait lines more uniformly over all clusters in SNC4, preventing this issue. Link: (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kerne...) Issue 2: In SNC4, the traffic targeting only remote clusters show much lower BW compared to the traffic targeting only local clusters Node 4 5 6 7 0 132,090 107,477 120,639 72,496 1 111,967 132,738 84,004 123,338 2 111,637 84,380 125,716 96,188 3 86,456 120,387 100,434 125,238 Root Cause: KNL follows YX routing for sending messages on the mesh. In SNC4 mode, when targeting all traffic to a remote cluster, the traffic (both address and data) predominantly flows in one direction: for example same Y and same X direction to go to the remote cluster that is diagonally across. This largely unidirectional flow cuts down effective BW on the mesh and causes congestion that results on further slowdowns. Mesh resources are provisioned for uniform distribution of traffic, such as those seen in Quadrant, all-to-all modes and local traffic in SNC4 mode. It is not provisioned for predominantly remote traffic in SNC4 mode. Fix: No HW or SW fix for this. Usage model needs to avoid drawing most of the traffic from remote clusters in SNC4 mode. They should keep the traffic local. If the access pattern is such that large amounts of remote traffic cannot be avoided then consider using Quadrant mode.