On 2015/12/21 22:27, Will Deacon wrote:
Mark,
On Fri, Dec 18, 2015 at 06:03:47PM +0000, Mark Rutland wrote:
On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
Hi Mark,
On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutl...@arm.com> wrote:
+- distance-matrix
+ This property defines a matrix to describe the relative distances
+ between all numa nodes.
+ It is represented as a list of node pairs and their relative distance.
+
+ Note:
+ 1. Each entry represents distance from first node to second node.
+ The distance are equal in either direction.
+ 2. The distance from a node to self(local distance) is represented
+ with value 10 and all inter node distance should be represented with
+ value greater than 10.
+ 3. distance-matrix shold have entries in lexicographical ascending
+ order of nodes.
+ 4. There must be only one Device node distance-map and must reside in the
root node.
I am still concerned that the local distance of 10 is completely
arbitrary.
IMHO, i do not see any issue in having defined local distance to
arbitrary number(10).
inter node numa distance is relative number with respect to local distance
we have to fix local distance to some value, having it in dt to make
generic will not add
any additional value as compared to having the fixed local distance to 10.
That's not quite true. The figure chosen for the local distance affects
the granularity with which you can describe all distances.
By using a local distance of 10 we can only encode distances in 10%
chunks of that. Using a local distance of 100 we could encode in 1%
chunks of that.
Whilst I see what you're saying, the local distance of 10 seems to be
part of the ACPI spec, and is the reason why the core code defines it
that way.
Now, we can of course do our own thing for device-tree, but I really
don't think it's worth our while to change this without a compelling
use-case.
I agree, that would simplify the kernel code as well.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
