| /linux/tools/perf/Documentation/ |
| A D | perf-c2c.txt | 199 - cacheline percentage of all peer accesses
208 - sum of all cachelines accesses
211 - sum of all load accesses
214 - sum of all store accesses
217 L1Hit - store accesses that hit L1
218 L1Miss - store accesses that missed L1
233 - count of local and remote DRAM accesses
251 - pid of the process responsible for the accesses
254 - tid of the process responsible for the accesses
257 - code address responsible for the accesses
[all …]
|
| /linux/arch/mips/kvm/ |
| A D | Kconfig | 34 bool "Maintain counters for COP0 accesses"
37 Maintain statistics for Guest COP0 accesses.
38 A histogram of COP0 accesses is printed when the VM is
|
| /linux/tools/memory-model/Documentation/ |
| A D | ordering.txt | 15 2. Ordered memory accesses. These operations order themselves
16 against some or all of the CPU's prior accesses or some or all
17 of the CPU's subsequent accesses, depending on the subcategory
20 3. Unordered accesses, as the name indicates, have no ordering
68 accesses against all subsequent accesses from the viewpoint of all CPUs.
89 CPU's accesses into three groups:
445 b. Unmarked C-language accesses.
498 Unmarked C-language accesses are normal variable accesses to normal
524 so that there are never concurrent conflicting accesses to
525 that variable. (There are "conflicting accesses" when
[all …]
|
| A D | access-marking.txt | 5 normal accesses to shared memory, that is "normal" as in accesses that do
7 document these accesses, both with comments and with special assertions
18 1. Plain C-language accesses (unmarked), for example, "a = b;"
39 Neither plain C-language accesses nor data_race() (#1 and #2 above) place
51 C-language accesses, but marking all accesses involved in a given data
60 data_race() and even plain C-language accesses is preferable to
135 the other accesses to the relevant shared variables. But please note
178 2. Initialization-time and cleanup-time accesses. This covers a
218 causes KCSAN to treat all accesses to that variable as if they were
303 the accesses to foo within both update_foo() and read_foo() can (and
[all …]
|
| A D | glossary.txt | 83 each pair of memory accesses, the outcome where r0, r1, and r2
118 its CPU's prior accesses with all of that CPU's subsequent
119 accesses, or a marked access such as atomic_add_return()
120 that orders all of its CPU's prior accesses, itself, and
121 all of its CPU's subsequent accesses.
123 Happens-Before (hb): A relation between two accesses in which LKMM
134 data between two CPUs requires that both CPUs their accesses.
|
| A D | cheatsheet.txt | 34 SELF: Orders self, as opposed to accesses before and/or after
35 SV: Orders later accesses to the same variable
|
| /linux/Documentation/i2c/ |
| A D | i2c-topology.rst | 83 This means that accesses to D2 are lockout out for the full duration
84 of the entire operation. But accesses to D3 are possibly interleaved
231 When device D1 is accessed, accesses to D2 are locked out for the
233 are locked). But accesses to D3 and D4 are possibly interleaved at
254 When device D1 is accessed, accesses to D2 and D3 are locked out
256 root adapter). But accesses to D4 are possibly interleaved at any
267 mux. In that case, any interleaved accesses to D4 might close M2
288 When D1 is accessed, accesses to D2 are locked out for the full
294 accesses, M1 locks the root adapter. For D4 accesses, the root
319 accesses to D5 may be interleaved at any time.
[all …]
|
| /linux/Documentation/dev-tools/ |
| A D | kcsan.rst | 85 It may be desirable to disable data race detection for specific accesses,
90 any data races due to accesses in ``expr`` should be ignored and resulting
95 to document that all data races due to accesses to a variable are intended
138 accesses are aligned writes up to word size.
200 In an execution, two memory accesses form a *data race* if they *conflict*,
263 compiler instrumenting plain accesses. For each instrumented plain access:
279 report the accesses.
313 concurrent accesses: because ``T2`` is able to proceed after the write of
321 the effects of "buffering" (delaying accesses), since the runtime cannot
324 means reordering of marked accesses is not modeled.
[all …]
|
| /linux/Documentation/ABI/testing/ |
| A D | sysfs-fs-ubifs | 8 This counter keeps track of the number of accesses of nodes
20 This counter keeps track of the number of accesses of nodes
32 This counter keeps track of the number of accesses of nodes
|
| /linux/drivers/acpi/acpica/ |
| A D | exprep.c | 65 u32 accesses; in acpi_ex_generate_access() local
115 accesses = field_end_offset - field_start_offset; in acpi_ex_generate_access()
124 accesses)); in acpi_ex_generate_access()
128 if (accesses <= 1) { in acpi_ex_generate_access()
140 if (accesses < minimum_accesses) { in acpi_ex_generate_access()
141 minimum_accesses = accesses; in acpi_ex_generate_access()
|
| /linux/Documentation/core-api/ |
| A D | unaligned-memory-access.rst | 15 unaligned accesses, why you need to write code that doesn't cause them,
22 Unaligned memory accesses occur when you try to read N bytes of data starting
59 - Some architectures are able to perform unaligned memory accesses
61 - Some architectures raise processor exceptions when unaligned accesses
64 - Some architectures raise processor exceptions when unaligned accesses
72 memory accesses to happen, your code will not work correctly on certain
103 to pad structures so that accesses to fields are suitably aligned (assuming
136 lead to unaligned accesses when accessing fields that do not satisfy
183 Here is another example of some code that could cause unaligned accesses::
202 Avoiding unaligned accesses
[all …]
|
| /linux/Documentation/admin-guide/hw-vuln/ |
| A D | special-register-buffer-data-sampling.rst | 8 infer values returned from special register accesses. Special register
9 accesses are accesses to off core registers. According to Intel's evaluation,
70 accesses from other logical processors will be delayed until the special
82 #. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other
84 legacy locked cache-line-split accesses.
91 processors memory accesses. The opt-out mechanism does not affect Intel SGX
|
| /linux/Documentation/devicetree/bindings/cache/ |
| A D | baikal,bt1-l2-ctl.yaml | 29 description: Cycles of latency for Way-select RAM accesses
36 description: Cycles of latency for Tag RAM accesses
43 description: Cycles of latency for Data RAM accesses
|
| /linux/Documentation/devicetree/bindings/ |
| A D | common-properties.txt | 13 - big-endian: Boolean; force big endian register accesses
16 - little-endian: Boolean; force little endian register accesses
19 - native-endian: Boolean; always use register accesses matched to the
30 default to LE for their MMIO accesses.
|
| /linux/Documentation/devicetree/bindings/mtd/ |
| A D | gpio-control-nand.txt | 10 resource describes the data bus connected to the NAND flash and all accesses
23 location used to guard against bus reordering with regards to accesses to
26 read to ensure that the GPIO accesses have completed.
|
| /linux/tools/memory-model/ |
| A D | linux-kernel.cat | 173 (* Plain accesses and data races *)
176 (* Warn about plain writes and marked accesses in the same region *)
177 let mixed-accesses = ([Plain & W] ; (po-loc \ barrier) ; [Marked]) |
179 flag ~empty mixed-accesses as mixed-accesses
186 (* Boundaries for lifetimes of plain accesses *)
194 (* Visibility and executes-before for plain accesses *)
204 (* Coherence requirements for plain accesses *)
|
| /linux/tools/memory-model/litmus-tests/ |
| A D | dep+plain.litmus | 6 * This litmus test demonstrates that in LKMM, plain accesses
7 * carry dependencies much like accesses to registers:
|
| A D | LB+unlocklockonceonce+poacquireonce.litmus | 6 * If two locked critical sections execute on the same CPU, all accesses
7 * in the first must execute before any accesses in the second, even if the
|
| A D | MP+polocks.litmus | 9 * given lock), a CPU is not only guaranteed to see the accesses that other
11 * to see all prior accesses by those other CPUs.
|
| A D | MP+porevlocks.litmus | 9 * given lock), a CPU is not only guaranteed to see the accesses that other
11 * see all prior accesses by those other CPUs.
|
| /linux/Documentation/hwmon/ |
| A D | w83627hf.rst | 5 * Winbond W83627HF (ISA accesses ONLY)
41 This driver implements support for ISA accesses *only* for
45 This driver supports ISA accesses, which should be more reliable
46 than i2c accesses. Also, for Tyan boards which contain both a
51 If you really want i2c accesses for these Super I/O chips,
|
| /linux/Documentation/arch/riscv/ |
| A D | hwprobe.rst | 247 the performance of misaligned scalar native word accesses on the selected set
251 misaligned scalar accesses is unknown.
254 accesses are emulated via software, either in or below the kernel. These
255 accesses are always extremely slow.
258 word sized accesses are slower than the equivalent quantity of byte
259 accesses. Misaligned accesses may be supported directly in hardware, or
263 word sized accesses are faster than the equivalent quantity of byte
264 accesses.
267 accesses are not supported at all and will generate a misaligned address
|
| A D | uabi.rst | 65 Misaligned accesses
68 Misaligned scalar accesses are supported in userspace, but they may perform
69 poorly. Misaligned vector accesses are only supported if the Zicclsm extension
|
| /linux/Documentation/process/ |
| A D | volatile-considered-harmful.rst | 39 meaning that data accesses will not be optimized across them. So the
43 accesses to that data.
53 registers. Within the kernel, register accesses, too, should be protected
55 accesses within a critical section. But, within the kernel, I/O memory
56 accesses are always done through accessor functions; accessing I/O memory
|
| /linux/Documentation/devicetree/bindings/iommu/ |
| A D | qcom,apq8064-iommu.yaml | 24 - description: interface clock for register accesses
25 - description: functional clock for bus accesses
|