| /Documentation/admin-guide/ |
| D | numastat.rst | 5 /sys/devices/system/node/node*/numastat
11 is incremented on the preferred node, otherwise numa_foreign is incremented on
12 the preferred node and numa_miss on the node where allocation succeeded.
14 Usually preferred node is the one local to the CPU where the process executes,
16 counters based on CPU local node. local_node is similar to numa_hit and is
17 incremented on allocation from a node by CPU on the same node. other_node is
18 similar to numa_miss and is incremented on the node where allocation succeeds
19 from a CPU from a different node. Note there is no counter analogical to
25 numa_hit A process wanted to allocate memory from this node,
28 numa_miss A process wanted to allocate memory from another node,
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices-node | 1 What: /sys/devices/system/node/possible
7 What: /sys/devices/system/node/online
13 What: /sys/devices/system/node/has_normal_memory
19 What: /sys/devices/system/node/has_cpu
25 What: /sys/devices/system/node/has_high_memory
32 What: /sys/devices/system/node/nodeX
37 information on node X such as what CPUs are local to the
38 node. Each file is detailed next.
40 What: /sys/devices/system/node/nodeX/cpumap
44 The node's cpumap.
[all …]
|
| D | sysfs-bus-firewire | 6 IEEE 1394 node device attributes.
7 Read-only. Mutable during the node device's lifetime.
15 The node's EUI-64 in the bus information block of
25 IEEE 1394 node device attribute.
26 Read-only. Mutable during the node device's lifetime.
30 Summary of all units present in an IEEE 1394 node.
32 version of each unit present in the node. Specifier_id
47 IEEE 1394 node device attribute.
49 Values: 1: The sysfs entry represents a local node (a controller card).
51 0: The sysfs entry represents a remote node.
[all …]
|
| D | firewire-cdev | 14 Each /dev/fw* is associated with one IEEE 1394 node, which can
18 - The 1394 node which is associated with the file:
22 - Query node ID
23 - Query maximum speed of the path between this node
24 and local node
26 - The 1394 bus (i.e. "card") to which the node is attached to:
34 - Query node IDs of local node, root node, IRM, bus
51 with a local node:
57 A /dev/fw* file remains associated with one particular node
59 node ID changes, are tracked by firewire-core. ABI users do not
|
| /Documentation/core-api/ |
| D | rbtree.rst | 65 struct rb_node node;
71 individual members may be accessed directly via rb_entry(node, type, member).
88 struct rb_node *node = root->rb_node;
90 while (node) {
91 struct mytype *data = container_of(node, struct mytype, node);
97 node = node->rb_left;
99 node = node->rb_right;
110 new node, then inserting the node and rebalancing ("recoloring") the tree.
113 location of the pointer on which to graft the new node. The new node also
114 needs a link to its parent node for rebalancing purposes.
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | cnxt,cx92755-pinctrl.txt | 7 === Pin Controller Node ===
14 - gpio-controller: Marks the device node as a GPIO controller.
19 For example, the following is the bare minimum node:
28 As a pin controller device, in addition to the required properties, this node
34 === Pin Configuration Node ===
36 Each pin configuration node is a sub-node of the pin controller node and is a
42 "pin configuration node".
44 === Pin Group Node ===
46 A pin group node specifies the desired pin mux for an arbitrary number of
47 pins. The name of the pin group node is optional and not used.
[all …]
|
| D | fsl,imx-pinctrl.txt | 12 phrase "pin configuration node".
14 Freescale IMX pin configuration node is a node of a group of pins which can be
15 used for a specific device or function. This node represents both mux and config
24 Required properties for pin configuration node:
46 1. We have pin function node defined under iomux controller node to represent
48 2. The pin configuration node intends to work on a specific function should
49 to be defined under that specific function node.
50 The function node's name should represent well about what function
51 this group of pins in this pin configuration node are working on.
52 3. The driver can use the function node's name and pin configuration node's
[all …]
|
| D | fsl,mxs-pinctrl.txt | 16 The node of mxs pin controller acts as a container for an arbitrary number of
25 Those subnodes under mxs pin controller node will fall into two categories.
27 configurations, and it's called group node in the binding document. The other
29 different configuration than what is defined in group node. The binding
30 document calls this type of node config node.
35 group node should include all the pins needed for one function rather than
37 "pinctrl-*" phandle in client device node should only have one group node
38 pointed in there, while the phandle can have multiple config node referenced
51 effects only on group node, and will get ignored by driver with config node,
52 since config node is only meant to set up pin configurations.
[all …]
|
| /Documentation/devicetree/bindings/ |
| D | numa.txt | 11 that comprise what is commonly known as a NUMA node.
12 Processor accesses to memory within the local NUMA node is generally faster
13 than processor accesses to memory outside of the local NUMA node.
14 DT defines interfaces that allow the platform to convey NUMA node
18 2 - numa-node-id
21 For the purpose of identification, each NUMA node is associated with a unique
22 token known as a node id. For the purpose of this binding
23 a node id is a 32-bit integer.
25 A device node is associated with a NUMA node by the presence of a
26 numa-node-id property which contains the node id of the device.
[all …]
|
| /Documentation/vm/ |
| D | swap_numa.rst | 4 Automatically bind swap device to numa node
7 If the system has more than one swap device and swap device has the node
17 for swap devices. e.g. on a 2 node machine, assume 2 swap devices swapA and
18 swapB, with swapA attached to node 0 and swapB attached to node 1, are going
24 Then node 0 will use the two swap devices in the order of swapA then swapB and
25 node 1 will use the two swap devices in the order of swapB then swapA. Note
28 A more complex example on a 4 node machine. Assume 6 swap devices are going to
29 be swapped on: swapA and swapB are attached to node 0, swapC is attached to
30 node 1, swapD and swapE are attached to node 2 and swapF is attached to node3.
40 Then node 0 will use them in the order of::
[all …]
|
| D | numa.rst | 57 For some architectures, such as x86, Linux will "hide" any node representing a
59 that cell to a node representing a cell that does have memory. Thus, on
61 a given node will see the same local memory access times and bandwidth.
66 nodes. Each emulated node will manage a fraction of the underlying cells'
72 For each node with memory, Linux constructs an independent memory management
77 selected zone/node cannot satisfy the allocation request. This situation,
83 fall back to the same zone type on a different node, or to a different zone
84 type on the same node. This is an important consideration because some zones,
86 a default Node ordered zonelist. This means it tries to fallback to other zones
87 from the same node before using remote nodes which are ordered by NUMA distance.
[all …]
|
| /Documentation/devicetree/bindings/powerpc/nintendo/ |
| D | gamecube.txt | 5 1) The "flipper" node
7 This node represents the multi-function "Flipper" chip, which packages
14 1.a) The Video Interface (VI) node
25 1.b) The Processor Interface (PI) node
35 1.b.i) The "Flipper" interrupt controller node
38 The node for the "Flipper" interrupt controller must be placed under
39 the PI node.
45 1.c) The Digital Signal Procesor (DSP) node
56 1.c.i) The Auxiliary RAM (ARAM) node
60 The ARAM node must be placed under the DSP node.
[all …]
|
| D | wii.txt | 5 0) The root node
7 This node represents the Nintendo Wii video game console.
14 1) The "hollywood" node
16 This node represents the multi-function "Hollywood" chip, which packages
23 1.a) The Video Interface (VI) node
34 1.b) The Processor Interface (PI) node
44 1.b.i) The "Flipper" interrupt controller node
47 The node for the "Flipper" interrupt controller must be placed under
48 the PI node.
56 1.c) The Digital Signal Procesor (DSP) node
[all …]
|
| /Documentation/devicetree/bindings/cpu/ |
| D | cpu-topology.txt | 39 2 - cpu-map node
42 The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct
43 child of the cpus node and provides a container where the actual topology
46 - cpu-map node
51 cpu-map node.
53 Description: The cpu-map node is just a container node where its
56 Node name must be "cpu-map".
58 The cpu-map node's parent node must be the cpus node.
60 The cpu-map node's child nodes can be:
67 The cpu-map node can only contain 4 types of child nodes:
[all …]
|
| /Documentation/devicetree/bindings/regulator/ |
| D | isl9305.txt | 7 - regulators: A node that houses a sub-node for each regulator within the
8 device. Each sub-node is identified using the node's name, with valid
9 values being "dcd1", "dcd2", "ldo1" and "ldo2". The content of each sub-node
11 - VINDCD1-supply: A phandle to a regulator node supplying VINDCD1.
12 VINDCD2-supply: A phandle to a regulator node supplying VINDCD2.
13 VINLDO1-supply: A phandle to a regulator node supplying VINLDO1.
14 VINLDO2-supply: A phandle to a regulator node supplying VINLDO2.
|
| /Documentation/driver-api/md/ |
| D | md-cluster.rst | 12 Separate write-intent-bitmaps are used for each cluster node.
13 The bitmaps record all writes that may have been started on that node,
24 one node writes to any given block at a time, so a write request will
31 one node doesn't read from a location where another node (or the same
32 node) is writing.
43 The bm_lockres protects individual node bitmaps. They are named in
44 the form bitmap000 for node 1, bitmap001 for node 2 and so on. When a
45 node joins the cluster, it acquires the lock in PW mode and it stays
46 so during the lifetime the node is part of the cluster. The lock
48 subsystem. Since DLM starts node count from one and bitmap slots
[all …]
|
| /Documentation/admin-guide/mm/ |
| D | numaperf.rst | 8 node. These disparate memory ranges may share some characteristics, such
14 characteristics. Some memory may share the same node as a CPU, and others
18 nodes with local memory and a memory only node for each of compute node::
21 | Compute Node 0 +-----+ Compute Node 1 |
29 A "memory initiator" is a node containing one or more devices such as
31 A "memory target" is a node containing one or more physical address
47 # symlinks -v /sys/devices/system/node/nodeX/access0/targets/
48 relative: /sys/devices/system/node/nodeX/access0/targets/nodeY -> ../../nodeY
50 # symlinks -v /sys/devices/system/node/nodeY/access0/initiators/
51 relative: /sys/devices/system/node/nodeY/access0/initiators/nodeX -> ../../nodeX
[all …]
|
| /Documentation/devicetree/bindings/hwlock/ |
| D | hwlock.txt | 25 - hwlocks: List of phandle to a hwlock provider node and an
37 1. Example of a node using a single specific hwlock:
39 The following example has a node requesting a hwlock in the bank defined by
40 the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
43 node {
49 2. Example of a node using multiple specific hwlocks:
51 The following example has a node requesting two hwlocks, a hwlock within
52 the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
53 hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
55 node {
|
| /Documentation/sphinx/ |
| D | kfigure.py | 104 node = nodes.literal_block(data, data)
105 return node
116 def pass_handle(self, node): # pylint: disable=W0613 argument
205 """Convert a image node for the builder.
338 def visit_kernel_image(self, node): # pylint: disable=W0613 argument
339 """Visitor of the ``kernel_image`` Node.
341 Handles the ``image`` child-node with the ``convert_image(...)``.
343 img_node = node[0]
347 """Node for ``kernel-image`` directive."""
354 *glob* pattern. The KernelImage wraps a image node into a
[all …]
|
| /Documentation/ABI/testing/ |
| D | ppc-memtrace | 14 you want removed from each NUMA node to this file - it must be
16 from each NUMA node in the kernel mappings and the following
18 removed from each node, the following files are created. To
22 What: /sys/kernel/debug/powerpc/memtrace/<node-id>
27 from the specific NUMA node.
29 What: /sys/kernel/debug/powerpc/memtrace/<node-id>/size
33 Description: This contains the size of the memory removed from the node.
35 What: /sys/kernel/debug/powerpc/memtrace/<node-id>/start
41 What: /sys/kernel/debug/powerpc/memtrace/<node-id>/trace
|
| /Documentation/devicetree/bindings/power/reset/ |
| D | syscon-reboot.yaml | 16 mask defined in the reboot node. Default will be little endian mode, 32 bit
18 parental dt-node. So the SYSCON reboot node should be represented as a
19 sub-node of a "syscon", "simple-mfd" node. Though the regmap property
20 pointing to the system controller node is also supported.
38 Phandle to the register map node. This property is deprecated in favor of
39 the syscon-reboot node been a child of a system controller node.
|
| /Documentation/devicetree/bindings/arm/ |
| D | cci.txt | 14 * CCI interconnect node
18 Node name must be "cci".
19 Node's parent must be the root node /, and the address space visible
21 root node (ie from CPUs perspective as per DT standard).
22 Every CCI node has to define the following properties:
48 interfaces addresses refer to the parent node
51 CCI interconnect node can define the following child nodes:
55 Node name must be "slave-if".
56 Parent node must be CCI interconnect node.
58 A CCI control interface node must contain the following
[all …]
|
| /Documentation/devicetree/bindings/net/ |
| D | fsl-enetc.txt | 11 to parent node bindings.
18 In this case, the ENETC node should include a "mdio" sub-node
19 that in turn should contain the "ethernet-phy" node describing the
31 - mdio : "mdio" node, defined in mdio.txt.
33 - ethernet-phy : "ethernet-phy" node, defined in phy.txt.
54 In this case, the mdio node should be defined as another PCIe
55 endpoint node, at the same level with the ENETC port nodes.
61 to parent node bindings.
89 In this case, the ENETC port node defines a fixed link connection,
94 - fixed-link : "fixed-link" node, defined in "fixed-link.txt".
|
| /Documentation/filesystems/ |
| D | ubifs-authentication.rst | 83 - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
95 UBIFS Index & Tree Node Cache
102 information like node type, node length, a sequence number, etc. (see
104 and some less important node types like padding nodes which are used to pad
113 a special node called *master node* into UBI LEB 1 which always points to the
114 most recent root node of the UBIFS index. For recoverability, the master node
116 LEB 1 and 2 to get the current master node and from there get the location of
120 additional runtime attributes per node which are not persisted. One of these is
141 ``mkfs.ubifs``) and stored in the superblock node. The log area contains only
143 node is written whenever an index commit is performed. Reference nodes are
[all …]
|
| /Documentation/devicetree/bindings/csky/ |
| D | cpus.txt | 6 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
9 Only SMP system need to care about the cpus node and single processor
10 needn't define cpus node at all.
13 cpus and cpu node bindings definition
16 - cpus node
20 The node name must be "cpus".
22 A cpus node must define the following properties:
33 - cpu node
|