| /linux/tools/perf/Documentation/ |
| A D | perf-c2c.txt | 178 - cacheline percentage of all Remote/Local HITM accesses
184 - sum of all cachelines accesses
187 - sum of all load accesses
190 - sum of all store accesses
193 L1Hit - store accesses that hit L1
194 L1Miss - store accesses that missed L1
206 - count of local and remote DRAM accesses
220 - pid of the process responsible for the accesses
223 - tid of the process responsible for the accesses
226 - code address responsible for the accesses
[all …]
|
| /linux/Documentation/i2c/ |
| A D | i2c-topology.rst | 261 When device D1 is accessed, accesses to D2 are locked out for the
263 are locked). But accesses to D3 and D4 are possibly interleaved at
264 any point. Accesses to D3 locks out D1 and D2, but accesses to D4
282 When device D1 is accessed, accesses to D2 and D3 are locked out
284 root adapter). But accesses to D4 are possibly interleaved at any
295 mux. In that case, any interleaved accesses to D4 might close M2
316 When D1 is accessed, accesses to D2 are locked out for the full
322 accesses, M1 locks the root adapter. For D4 accesses, the root
346 When D1 is accessed, accesses to D2, D3 and D4 are locked out. But
347 accesses to D5 may be interleaved at any time.
[all …]
|
| /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
17 1. Plain C-language accesses (unmarked), for example, "a = b;"
33 Neither plain C-language accesses nor data_race() (#1 and #2 above) place
45 C-language accesses, but marking all accesses involved in a given data
54 data_race() and even plain C-language accesses is preferable to
129 the other accesses to the relevant shared variables. But please note
172 2. Initialization-time and cleanup-time accesses. This covers a
280 the accesses to foo within both update_foo() and read_foo() can (and
281 should) be plain C-language accesses. One benefit of making them be
[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 | explanation.txt | 151 accesses by the CPUs.
357 that add memory accesses, eliminate accesses, combine them, split them
370 memory accesses in the examples.
528 accesses are used. Consider this example:
1927 accesses such as x or y = 0 are simply called "plain" accesses.
2109 accesses.
2136 ... some memory accesses ...
2138 ... some other memory accesses ...
2153 marked accesses.
2156 again, now using plain accesses for buf:
[all …]
|
| 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/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/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/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/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/tools/memory-model/ |
| A D | linux-kernel.cat | 160 (* Plain accesses and data races *)
163 (* Warn about plain writes and marked accesses in the same region *)
164 let mixed-accesses = ([Plain & W] ; (po-loc \ barrier) ; [Marked]) |
166 flag ~empty mixed-accesses as mixed-accesses
173 (* Boundaries for lifetimes of plain accesses *)
181 (* Visibility and executes-before for plain accesses *)
191 (* Coherence requirements for plain accesses *)
|
| /linux/Documentation/devicetree/bindings/memory-controllers/ |
| 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/dev-tools/ |
| A D | kcsan.rst | 78 the racing thread, but could also occur due to e.g. DMA accesses. Such reports
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
128 accesses are aligned writes up to word size.
190 In an execution, two memory accesses form a *data race* if they *conflict*,
243 address set up, and then observe the watchpoint to fire, two accesses to the
253 compiler instrumenting plain accesses. For each instrumented plain access:
264 To detect data races between plain and marked accesses, KCSAN also annotates
265 marked accesses, but only to check if a watchpoint exists; i.e. KCSAN never
266 sets up a watchpoint on marked accesses. By never setting up watchpoints for
[all …]
|
| A D | kasan.rst | 27 out-of-bounds accesses for global variables is only supported since Clang 11.
240 memory accesses are valid or not by checking corresponding shadow memory.
272 emits callbacks to check memory accesses; and inline, which performs the shadow
335 declares all memory accesses as permitted.
340 This allows detection of invalid accesses to module globals, for example.
382 Ignoring accesses
390 Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
391 in memory allocators), these accesses are valid.
410 per-function basis) makes KASAN ignore the accesses that happen directly in
411 that code for software KASAN modes. It does not help when the accesses happen
[all …]
|
| /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/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/lib/ |
| A D | Kconfig.ubsan | 53 array accesses, where the array size is known at compile time.
82 Enabling this option detects errors due to accesses through a
116 bool "Perform checking for accesses beyond the end of objects"
123 This option enables -fsanitize=object-size which checks for accesses
150 This option enables the check of unaligned memory accesses.
152 accesses may produce a lot of false positives.
|
| A D | Kconfig.kasan | 44 designed to find out-of-bounds accesses and use-after-free bugs.
77 but detection of out-of-bounds accesses for global variables is
145 memory accesses. This is faster than outline (in some workloads
199 out of bounds and use after free accesses. It is useful for testing
211 accesses.
|
| /linux/tools/memory-model/litmus-tests/ |
| 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.
|
| A D | README | 40 litmus test is visible to an external process whose accesses are
141 spin_lock() sufficient to make ordering apparent to accesses
150 to make ordering apparent to accesses by a process that does
173 Each class defines the pattern of accesses and of the variables accessed.
206 accesses with descriptions of the second access in the pair.
220 to a different variable ("d"), and both accesses are reads ("RR").
246 The descriptors that describe connections between consecutive accesses
|
| /linux/Documentation/driver-api/ |
| A D | device-io.rst | 30 part of the CPU's address space is interpreted not as accesses to
31 memory, but as accesses to a device. Some architectures define devices
54 historical accident, these are named byte, word, long and quad accesses.
55 Both read and write accesses are supported; there is no prefetch support
127 addresses is generally not as fast as accesses to the memory mapped
137 allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and
143 that accesses to their ports are slowed down. This functionality is
172 MMIO accesses and DMA accesses as well as fixed endianness for accessing
223 on 32-bit architectures but allow two consecutive 32-bit accesses instead.
327 On many platforms, I/O accesses must be aligned with respect to the access
[all …]
|
| /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
|