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.
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: "Leizhen (ThunderTown)" <thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"steve.capper-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<steve.capper-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"arnd-r2nGTMty4D4@public.gmane.org"
<arnd-r2nGTMty4D4@public.gmane.org>,
"al.stone-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<al.stone-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
"ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org"
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org"
<rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>,
"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
"hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Ganapatrao Kulkarni
<gkulkarni-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM9gwCICpdfJQ@public.gmane.org>
Subject: Re: [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-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.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.
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-08-31 1:46 UTC|newest]
Thread overview: 94+ 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 ` Ganapatrao Kulkarni
2015-08-14 16:39 ` [PATCH v5 1/4] arm64, numa: adding " Ganapatrao Kulkarni
2015-08-14 16:39 ` Ganapatrao Kulkarni
2015-09-03 9:52 ` Ganapatrao Kulkarni
2015-09-03 9:52 ` Ganapatrao Kulkarni
2015-09-03 10:13 ` Will Deacon
2015-09-03 10:13 ` Will Deacon
2015-09-29 8:43 ` Ganapatrao Kulkarni
2015-09-29 8:43 ` Ganapatrao Kulkarni
2015-10-05 5:24 ` 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-14 16:39 ` Ganapatrao Kulkarni
2015-08-22 15:06 ` Robert Richter
2015-08-22 15:06 ` Robert Richter
2015-08-23 21:49 ` Rob Herring
2015-08-23 21:49 ` Rob Herring
2015-08-28 11:32 ` Matthias Brugger
2015-08-28 11:32 ` Matthias Brugger
2015-08-28 12:32 ` Mark Rutland
2015-08-28 12:32 ` Mark Rutland
2015-08-28 14:02 ` Rob Herring
2015-08-28 14:02 ` Rob Herring
2015-08-28 21:37 ` Benjamin Herrenschmidt
2015-08-28 21:37 ` Benjamin Herrenschmidt
2015-09-02 17:11 ` Ganapatrao Kulkarni
2015-09-02 17:11 ` Ganapatrao Kulkarni
2015-08-29 9:46 ` Leizhen (ThunderTown)
2015-08-29 9:46 ` Leizhen (ThunderTown)
2015-08-29 10:37 ` Benjamin Herrenschmidt
2015-08-29 10:37 ` Benjamin Herrenschmidt
2015-08-31 1:46 ` Leizhen (ThunderTown) [this message]
2015-08-31 1:46 ` Leizhen (ThunderTown)
2015-08-29 14:56 ` Ganapatrao Kulkarni
2015-08-29 14:56 ` Ganapatrao Kulkarni
2015-08-31 2:53 ` Leizhen (ThunderTown)
2015-08-31 2:53 ` Leizhen (ThunderTown)
2015-09-08 13:27 ` Hanjun Guo
2015-09-08 13:27 ` Hanjun Guo
2015-09-08 16:27 ` Ganapatrao Kulkarni
2015-09-08 16:27 ` Ganapatrao Kulkarni
2015-09-11 3:53 ` Ganapatrao Kulkarni
2015-09-11 3:53 ` Ganapatrao Kulkarni
2015-09-11 6:43 ` Leizhen (ThunderTown)
2015-09-11 6:43 ` Leizhen (ThunderTown)
2015-09-29 8:35 ` Ganapatrao Kulkarni
2015-09-29 8:38 ` Ganapatrao Kulkarni
2015-09-29 8:38 ` Ganapatrao Kulkarni
2015-09-29 9:42 ` Benjamin Herrenschmidt
2015-09-29 9:42 ` Benjamin Herrenschmidt
2015-09-30 0:28 ` Benjamin Herrenschmidt
2015-09-30 0:28 ` Benjamin Herrenschmidt
2015-09-30 10:19 ` Ganapatrao Kulkarni
2015-09-30 10:19 ` Ganapatrao Kulkarni
2015-09-30 10:53 ` Mark Rutland
2015-09-30 10:53 ` Mark Rutland
2015-09-30 17:50 ` Ganapatrao Kulkarni
2015-09-30 17:50 ` Ganapatrao Kulkarni
2015-10-01 1:05 ` Benjamin Herrenschmidt
2015-10-01 1:05 ` Benjamin Herrenschmidt
2015-10-01 5:11 ` Ganapatrao Kulkarni
2015-10-01 5:25 ` Ganapatrao Kulkarni
2015-10-01 5:25 ` Ganapatrao Kulkarni
2015-10-01 7:17 ` Benjamin Herrenschmidt
2015-10-01 7:17 ` Benjamin Herrenschmidt
2015-10-01 11:36 ` Ganapatrao Kulkarni
2015-10-01 11:36 ` Ganapatrao Kulkarni
2015-10-13 16:47 ` Mark Rutland
2015-10-13 16:47 ` Mark Rutland
2015-10-13 17:07 ` Ganapatrao Kulkarni
2015-10-13 17:07 ` Ganapatrao Kulkarni
2015-10-14 13:21 ` Hanjun Guo
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-08-14 16:39 ` Ganapatrao Kulkarni
2015-10-09 15:18 ` Catalin Marinas
2015-10-09 15:18 ` Catalin Marinas
2015-10-09 16:51 ` Ganapatrao Kulkarni
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-14 16:39 ` Ganapatrao Kulkarni
2015-08-18 6:16 ` Jisheng Zhang
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-14 16:44 ` Ganapatrao Kulkarni
2015-08-20 6:50 ` Ganapatrao Kulkarni
2015-08-20 6:50 ` Ganapatrao Kulkarni
2015-08-28 14:31 ` Matthias Brugger
2015-08-28 14:31 ` Matthias Brugger
2015-08-28 14:59 ` Ganapatrao Kulkarni
2015-08-28 14:59 ` Ganapatrao Kulkarni
2015-08-28 15:36 ` Matthias Brugger
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.