From: Khalid Aziz <khalid.aziz@xxxxxxxxxx> Date: Thu, 7 Jan 2016 18:24:35 -0700 > I don't mean to be nitpicking, just want to make sure "numa=off" > behavior gets handled correctly. With this code change, > node_distance() will return either LOCAL_DISTANCE or REMOTE_DISTANCE > even when kernel is booted up with "numa=off". Would that end up not > honoring "numa=off"? Should this loop initialize all numa_latency > elements to LOCAL_DISTANCE if numa_enabled is not true, otherwise to > LOCAL_DISTANCE and REMOTE_DISTANCE as appropriate? Please do let me > know if it really is not a concern here. Considering this further, we want to preserve the exact behavior that occurs before the patch that got bisected to. And that behavior is to use the default definition of node_distance() which is: #define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE) which is completely not influenced by "numa_enabled" at all. So, we should setup the default table values regardless of the "numa_enabled" value when CONFIG_NUMA is enabled, and that is exactly what this v2 patch is doing. So I will apply this, and queue it up for -stable. Thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
