linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thunder.leizhen@huawei.com (Leizhen (ThunderTown))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.
Date: Mon, 31 Aug 2015 09:46:48 +0800	[thread overview]
Message-ID: <55E3B208.3020404@huawei.com> (raw)
In-Reply-To: <1440844631.2912.248.camel@kernel.crashing.org>



On 2015/8/29 18:37, Benjamin Herrenschmidt wrote:
> On Sat, 2015-08-29 at 17:46 +0800, Leizhen (ThunderTown) wrote:
>> Why not copy the method of ACPI numa? There only three elements
>> should be configured:
>> 1) a cpu belong to which node
>> 2) a memory block belong to which node
>> 3) the distance of each two nodes

Sorry, I forgot to write something:
4) a device(maybe a bus device) belongs to which node

For example:
device-name {
        ...
        numa-node = <&node0>;
};

To simplify the discussion, I will not mention device again. Treat both
cpus and devices as masters, memorys as slaves.

A bus is not a master, we allow binding numa node to a bus, because we may
want all devices on the bus to inherit its numa node-id without obvious configured one by one.

> 
> This means your are bolting into the DT representation the concept of
> "Node" which isn't necessarily very meaningful.
> 
> Your system is really a hierarchy of objects. You can have cores on a
> chip, already possibly sharing some level of cache or not, you can have
> chips on a module, modules linked at various distances, etc...
> 
> What is "a node" ?
> 
> For example, I have a P8 chip with 2 chips on a module (fast X-bus) and
> 2 modules (slightly slower A-bus). All 4 chips have 2 memory
> controllers each.
> 
> Is a "node" a chip or a module ?

A numa node is a abstract concept, it needn't related to a real hardware level.
A numa node normally contains both cpus and mems, but may only contains cpus or mems,
or maybe nothing(quite rare). We put cpus or mems into a node, because we want to use
node-distance to implement the nearest memory access, the nearest process schedule.

In your example:
On fast X-bus, have a module contains 2 chips.
On slightly slower A-bus, have 2 modules(treat them as 2 chips).
Each chip contains 2 memory controllers.

Suppose each chip access its local bus memory faster than another.

Case1:
Each chip access its 2 local memory controllers faster than others. Then we can define numa nodes:
node-xbus-0: a chip and 2 local memory.
node-xbus-1: a chip and 2 local memory.
node-abus-0: a chip(module) and 2 local memory.
node-abus-1: a chip(module) and 2 local memory.

Case2:
Each chip access any memory controllers on its local bus are the same. Then we can define numa nodes:
node-xbus: 2 chips and 4 local memory.
node-abus: 2 chips(modules) and 4 local memory.


> 
> The Linux concept of node is too restrictive. The associativity
> properties avoid this by allowing you to define as many "levels" of
> associativity as you wish. Also since it's right justified, a given
> component doesn't need to have all levels (a MC can stop at chip while
> cores can go down one more level for example).
> 
> The reference points property gives a hint as "interesting" levels can
> typically be used as a hint for chosing what Linux will use as a "node"
> at least until Linux gets smarter. It can also be used to calculate
> distances.
> 
> Cheers,
> Ben.
> 
> 
> .
> 

  reply	other threads:[~2015-08-31  1:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 16:39 [PATCH v5 0/8] arm64, numa: Add numa support for arm64 platforms Ganapatrao Kulkarni
2015-08-14 16:39 ` [PATCH v5 1/4] arm64, numa: adding " Ganapatrao Kulkarni
2015-09-03  9:52   ` Ganapatrao Kulkarni
2015-09-03 10:13     ` Will Deacon
2015-09-29  8:43       ` Ganapatrao Kulkarni
2015-10-05  5:24   ` Ganapatrao Kulkarni
2015-08-14 16:39 ` [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa Ganapatrao Kulkarni
2015-08-22 15:06   ` Robert Richter
2015-08-23 21:49   ` Rob Herring
2015-08-28 11:32   ` Matthias Brugger
2015-08-28 12:32   ` Mark Rutland
2015-08-28 14:02     ` Rob Herring
2015-08-28 21:37       ` Benjamin Herrenschmidt
2015-09-02 17:11         ` Ganapatrao Kulkarni
2015-08-29  9:46       ` Leizhen (ThunderTown)
2015-08-29 10:37         ` Benjamin Herrenschmidt
2015-08-31  1:46           ` Leizhen (ThunderTown) [this message]
2015-08-29 14:56         ` Ganapatrao Kulkarni
2015-08-31  2:53           ` Leizhen (ThunderTown)
2015-09-08 13:27           ` Hanjun Guo
2015-09-08 16:27             ` Ganapatrao Kulkarni
2015-09-11  3:53               ` Ganapatrao Kulkarni
2015-09-11  6:43                 ` Leizhen (ThunderTown)
     [not found]     ` <CAFpQJXWzM644KsFWP9ei-k6gWgNVpBVT+UbY7NYdyfmyL=zMkw@mail.gmail.com>
2015-09-29  8:38       ` Ganapatrao Kulkarni
2015-09-29  9:42         ` Benjamin Herrenschmidt
2015-09-30  0:28         ` Benjamin Herrenschmidt
2015-09-30 10:19           ` Ganapatrao Kulkarni
2015-09-30 10:53         ` Mark Rutland
2015-09-30 17:50           ` Ganapatrao Kulkarni
2015-10-01  1:05             ` Benjamin Herrenschmidt
     [not found]               ` <CAFpQJXXKcwks0iZN+3B=U0-9uYKFpAXcZE90GCHN9WyM45Hdpw@mail.gmail.com>
2015-10-01  5:25                 ` Ganapatrao Kulkarni
2015-10-01  7:17                 ` Benjamin Herrenschmidt
2015-10-01 11:36                 ` Ganapatrao Kulkarni
2015-10-13 16:47                   ` Mark Rutland
2015-10-13 17:07                     ` Ganapatrao Kulkarni
2015-10-14 13:21                     ` Hanjun Guo
2015-08-14 16:39 ` [PATCH v5 3/4] arm64, numa, dt: adding dt based numa support using dt node property arm, associativity Ganapatrao Kulkarni
2015-10-09 15:18   ` Catalin Marinas
2015-10-09 16:51     ` Ganapatrao Kulkarni
2015-08-14 16:39 ` [PATCH v5 4/4] arm64, dt, thunderx: Add initial dts for Cavium Thunder SoC in 2 Node topology Ganapatrao Kulkarni
2015-08-18  6:16   ` Jisheng Zhang
2015-08-14 16:44 ` [PATCH v5 0/8] arm64, numa: Add numa support for arm64 platforms Ganapatrao Kulkarni
2015-08-20  6:50   ` Ganapatrao Kulkarni
2015-08-28 14:31 ` Matthias Brugger
2015-08-28 14:59   ` Ganapatrao Kulkarni
2015-08-28 15:36     ` Matthias Brugger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E3B208.3020404@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).