[RFC PATCH] dt:numa: adding numa node mapping for memory nodes.

[Ganapatrao Kulkarni]

looks like previous email not had the email ids added by kumar gala.
adding the missing ids and sending again.

On Thu, Sep 18, 2014 at 9:32 AM, Ganapatrao Kulkarni
<gpkulkarni at gmail.com> wrote:
> On Thu, Sep 18, 2014 at 4:42 AM, Zi Shen Lim <zlim.lnx at gmail.com> wrote:
>> On Wed, Sep 17, 2014 at 2:48 PM, Nathan Lynch <Nathan_Lynch at mentor.com> wrote:
>>> On 09/17/2014 03:56 AM, Ganapatrao Kulkarni wrote:
>>>> From: Ganapatrao Kulkarni <ganapatrao.kulkarni at cavium.com>
>>>>
>>>> This patch adds property "nid" to memory node to provide the memory range to
>>>> numa node id mapping.
>>>>
>>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni at cavium.com>
>>>>
>>>> ---
>>>>  Documentation/devicetree/bindings/numa.txt | 58 ++++++++++++++++++++++++++++++
>>>>  1 file changed, 58 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/numa.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
>>>> new file mode 100644
>>>> index 0000000..c4a94f2
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/numa.txt
>>>> @@ -0,0 +1,58 @@
>>>> +======================================================
>>>> +numa id binding description
>>>> +======================================================
>>>> +
>>>> +======================================================
>>>> +1 - Introduction
>>>> +======================================================
>>>> +The device node  property "nid(numa node id)" can be added to memory
>>>> +device node to map the range of memory addresses as defined in property "reg".
>>>> +The property "nid" maps the memory range to the numa node id, which is used to
>>>> +find the local and remory pages on numa aware systems.
>>>
>>> "Local" and "remote" memory are notions that relate to some other
>>> resource -- typically a CPU, but also I/O resources on some systems.  It
>>> seems to me that a useful NUMA binding would at least specify a "nid"
>>> property, or something like it, for both cpu and memory nodes.  But this
>>> document speaks only of memory nodes.
> IMO, nid can be extended to cpu node also if the arch dont have any
> other way to do mapping, in fact this can be scaled to any node.
> for ARM arch, cpu mapping can be fetched from topology parsing and
> more over cpu mapping is required much later when secondary cpus comes
> online.
> i have added for memory, since this is parsed very early in the boot
> sequence and there is no support for dt based map at this moment(at
> least i am not aware off).
> numa distance matrix can also be defined, if the architecture has
> variable node distance other than just local/remote.
>>>
>>> As Kumar said, the device tree on powerpc server systems already has
>>> properties that express NUMA information.  If you can get hold of a copy
>>> of the PAPR (not ePAPR) from power.org, refer to the description of
>>> "ibm,associativity" and related properties.  I recall that it's a bit
>>> more complex than this proposal, though.
>>
>> I'm not able to find a link to the actual PAPR (not ePAPR)
>> specification. Anyone has a linky?
>>
>> I did find some code in tree, but couldn't find the bindings in
>> Documentation/devicetree/.
> yes, there is nothing in Documentation, if PPC are using since several
> years, then i humbly request to publish the documentation for numa
> bindings.
> No point in reinventing the wheel. Also i did not find any spec named
> PAPR, is it open spec, available to all like ePAPR?
>
>>
>> Seems like we'd care about form1?
>> -----8<-----
>> commit 41eab6f88f24124df89e38067b3766b7bef06ddb
>> Author: Anton Blanchard <anton at samba.org>
>> Date:   Sun May 16 20:22:31 2010 +0000
>>
>>     powerpc/numa: Use form 1 affinity to setup node distance
>>
>>     Form 1 affinity allows multiple entries in
>> ibm,associativity-reference-points
>>     which represent affinity domains in decreasing order of importance. The
>>     Linux concept of a node is always the first entry, but using the other
>>     values as an input to node_distance() allows the memory allocator to make
>>     better decisions on which node to go first when local memory has been
>>     exhausted.
>>
>>     We keep things simple and create an array indexed by NUMA node, capped at
>>     4 entries. Each time we lookup an associativity property we initialise
>>     the array which is overkill, but since we should only hit this path during
>>     boot it didn't seem worth adding a per node valid bit.
>>
>>     Signed-off-by: Anton Blanchard <anton at samba.org>
>>     Signed-off-by: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>> ----->8-----
>>
>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel