| /openbmc/linux/tools/perf/Documentation/ |
| H A D | perf-c2c.txt | 37 for cachelines with highest contention - highest number of HITM accesses.
196 - cacheline percentage of all Remote/Local HITM accesses
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
219 N/A - store accesses with memory level is not available
225 - count of LLC load accesses, includes LLC hits and LLC HITMs
[all …]
|
| /openbmc/linux/Documentation/riscv/ |
| H A D | hwprobe.rst | 84 accesses is unknown.
86 * :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
87 emulated via software, either in or below the kernel. These accesses are
90 * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are slower
91 than equivalent byte accesses. Misaligned accesses may be supported
94 * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are faster
95 than equivalent byte accesses.
97 * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
|
| /openbmc/qemu/tests/bench/ |
| H A D | atomic64-bench.c | 14 uint64_t accesses; member
70 info->accesses++; in thread_func()
104 info->accesses = 0; in create_threads()
125 val += th_info[i].accesses; in pr_stats()
|
| /openbmc/linux/Documentation/dev-tools/ |
| H 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*,
236 KCSAN relies on observing that two accesses happen concurrently. Crucially, we
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
[all …]
|
| /openbmc/linux/tools/memory-model/Documentation/ |
| H 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
48 a device driver, which must correctly order accesses to a physical
68 accesses against all subsequent accesses from the viewpoint of all CPUs.
89 CPU's accesses into three groups:
245 The Linux kernel provides a wide variety of ordered memory accesses:
264 of the CPU's prior memory accesses. Release operations often provide
323 memory accesses. Acquire operations often provide improved performance
[all …]
|
| H 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
40 C-language accesses. It is permissible to combine #2 and #3, for example,
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
82 reads can enable better checking of the remaining accesses implementing
129 the other accesses to the relevant shared variables. But please note
166 Here are some example situations where plain C-language accesses should
[all …]
|
| /openbmc/linux/Documentation/i2c/ |
| H 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
165 This means that accesses to both D2 and D3 are locked out for the full
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
236 Accesses to D3 locks out D1 and D2, but accesses to D4 are still possibly
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
[all …]
|
| /openbmc/linux/Documentation/core-api/ |
| H 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::
192 This code will cause unaligned accesses every time the data parameter points
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.unaligned-memory-access.txt | 9 unaligned accesses, why you need to write code that doesn't cause them,
16 Unaligned memory accesses occur when you try to read N bytes of data starting
53 - Some architectures are able to perform unaligned memory accesses
55 - Some architectures raise processor exceptions when unaligned accesses
58 - Some architectures raise processor exceptions when unaligned accesses
66 memory accesses to happen, your code will not work correctly on certain
97 to pad structures so that accesses to fields are suitably aligned (assuming
130 lead to unaligned accesses when accessing fields that do not satisfy
177 Here is another example of some code that could cause unaligned accesses:
185 This code will cause unaligned accesses every time the data parameter points
[all …]
|
| /openbmc/linux/arch/mips/kvm/ |
| H A D | Kconfig | 35 bool "Maintain counters for COP0 accesses"
38 Maintain statistics for Guest COP0 accesses.
39 A histogram of COP0 accesses is printed when the VM is
|
| /openbmc/qemu/contrib/plugins/ |
| H A D | cache.c | 79 uint64_t accesses; member
267 cache->accesses = 0; in cache_init()
412 l1_dcaches[cache_idx]->accesses++; in vcpu_mem_access()
426 l2_ucaches[cache_idx]->accesses++; in vcpu_mem_access()
447 l1_icaches[cache_idx]->accesses++; in vcpu_insn_exec()
461 l2_ucaches[cache_idx]->accesses++; in vcpu_insn_exec()
569 l1_imem_accesses += l1_icaches[i]->accesses; in sum_stats()
570 l1_dmem_accesses += l1_dcaches[i]->accesses; in sum_stats()
574 l2_mem_accesses += l2_ucaches[i]->accesses; in sum_stats()
623 append_stats_line(rep, dcache->accesses, dcache->misses, in log_stats()
[all …]
|
| /openbmc/linux/drivers/acpi/acpica/ |
| H 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()
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H 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
|
| /openbmc/linux/Documentation/admin-guide/hw-vuln/ |
| H 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
|
| /openbmc/qemu/docs/devel/ |
| H A D | secure-coding-practices.rst | 46 accesses and data read from guest memory must be validated. A typical example
76 may make nonsense accesses to device registers such as starting operations
80 device register accesses while asynchronous operations are in progress. A
84 request completes. Unexpected accesses must not cause memory corruption or
87 Invalid device register accesses can be reported with
111 The ``null-co`` block driver is designed for performance: its read accesses are
|
| H A D | atomics.rst | 19 and atomic operations. The semantics of concurrent memory accesses are governed
47 ``barrier()`` prevents the compiler from moving the memory accesses on
118 - atomic accesses will not cause data races (and hence undefined behavior);
119 ordinary accesses instead cause data races if they are concurrent with
120 other accesses of which at least one is a write. In order to ensure this,
121 the compiler will not optimize accesses out of existence, create unsolicited
122 accesses, or perform other similar optimizations.
138 optimizing accesses out of existence and creating unsolicited
139 accesses, but do not otherwise impose any ordering on loads and
155 Restrictions to the ordering of accesses can also be specified
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/ |
| H 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.
|
| /openbmc/linux/tools/memory-model/ |
| H 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 *)
|
| /openbmc/linux/Documentation/devicetree/bindings/mtd/ |
| H 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.
|
| /openbmc/linux/Documentation/hwmon/ |
| H 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,
|
| /openbmc/linux/tools/memory-model/litmus-tests/ |
| H A D | dep+plain.litmus | 6 * This litmus test demonstrates that in LKMM, plain accesses
7 * carry dependencies much like accesses to registers:
|
| H 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
|
| H 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.
|
| H 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.
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-benchmark/tinymembench/ |
| H A D | tinymembench_git.bb | 2 peak bandwidth of sequential memory accesses and the latency of random memory \
3 accesses. Bandwidth is measured by running different assembly code for the \
|