Searched refs:its (Results 1 – 25 of 50) sorted by relevance
12
| /tools/bpf/bpftool/Documentation/ |
| D | bpftool-struct_ops.rst | 45 Output will start with struct_ops map ID, followed by its map
46 name and its struct_ops's kernel type.
57 be registered to its kernel subsystem. For each
|
| D | bpftool-link.rst | 58 Force-detach link *LINK*. BPF link and its underlying BPF
|
| D | bpftool-map.rst | 139 receiving events if it installed its rings earlier.
160 and the map remains immutable from user space until its
|
| /tools/testing/selftests/tc-testing/ |
| D | TODO.txt | 8 - Improve error messages when tdc aborts its run. Partially done - still
13 - Allow tdc to write its results to file.
|
| /tools/perf/Documentation/ |
| D | perf-buildid-list.txt | 39 its modules.
|
| D | callchain-overhead-calculation.txt | 17 'self' overhead of its child functions. But with this enabled, users
105 is sorted by its values. The 'children' overhead is disabled by
|
| D | perf.data-file-format.txt | 49 defines its size.
297 Physical memory map and its node assignments.
394 Contains clock id and its reference time together with wall clock
477 In addition to the kernel generated event types perf record adds its
|
| D | perf-script-python.txt | 39 of its output (syscall names are not yet supported, they will appear
117 perf-script.py. Here's the file in its entirety:
185 and its parameter values to stdout. The print_header() function is
271 The final script producing the output shown above is shown in its
427 the check-perf-script.py script, while not interesting for its results,
|
| D | perf-sched.txt | 31 it a number of times, measuring its performance.)
|
| D | perf-config.txt | 38 aspects of each of its tools, including output, disk usage, etc.
54 The file consist of sections. A section starts with its name
395 the instruction. When set to '2' 'call' instructions will also have its offsets
473 'callee' which means callee is printed at top and then followed by its
|
| /tools/testing/selftests/arm64/signal/ |
| D | README | 14 - Each signal testcase is compiled into its own executable: a separate
17 to run each test unit in its own standalone process, so as to start each
|
| /tools/perf/util/ |
| D | python-ext-sources | 4 # Each source file must be placed on its own line so that it can be
|
| /tools/memory-model/scripts/ |
| D | README | 29 Check a single litmus test against its "Result:" expected result.
54 Given a .litmus file and its herd7 output, check the output file
|
| /tools/testing/selftests/sgx/ |
| D | test_encl_bootstrap.S | 51 # its stack directly.
|
| /tools/memory-model/Documentation/ |
| D | control-dependencies.txt | 49 "a" is always non-zero, it would be well within its rights to optimize
88 "b", which means that the CPU is within its rights to reorder them: The
134 The compiler is therefore within its rights to transform the above code
180 within its rights to discard the loaded value.
|
| D | glossary.txt | 118 its CPU's prior accesses with all of that CPU's subsequent
120 that orders all of its CPU's prior accesses, itself, and
121 all of its CPU's subsequent accesses.
|
| D | locking.txt | 135 The smp_load_acquire() guarantees that its load from "flags" will
137 problem. The smp_store_release() guarantees that its store will be
262 Then the "exists" clause checks to see if CPU1() acquired its lock first,
|
| D | ordering.txt | 12 all of the CPU's prior operations against some or all of its
33 Each of the following categories of barriers is described in its own
122 to also rely on its additional full-memory-barrier semantics. Just please
233 Without the barrier(), the compiler would be within its rights to move the
238 Note that the barriers discussed previously use barrier() or its low-level
255 Each of the above categories has its own section below.
|
| D | explanation.txt | 154 A memory model will predict what values P1 might obtain for its loads
185 if each CPU executed its instructions in order but with unspecified
204 would be 1 since a load obtains its value from the most recent
208 its instructions in order.
223 each CPU stores to its own shared location and then loads from the
319 is concerned only with the store itself -- its value and its address
559 of load-tearing, where a load obtains some of its bits from one store
662 of its requirements look more like hardware bugs than programming
732 prefer, each location has its own independent coherence order.
792 special case, we say that the store propagates to its own CPU at the
[all …]
|
| /tools/perf/pmu-events/ |
| D | README | 14 - The CSV file that maps a specific CPU to its set of PMU events is to
61 - A 'mapping table' that maps each CPU of the architecture, to its
|
| /tools/usb/usbip/ |
| D | COPYING | 14 software--to make sure the software is free for all its users. This
46 want its recipients to know that what they have is not the original, so
73 covered by this License; they are outside its scope. The act of
75 is covered only if its contents constitute a work based on the
117 themselves, then this License, and its terms, do not apply to those
182 distribute the Program or its derivative works. These actions are
186 all its terms and conditions for copying, distributing or modifying
|
| /tools/objtool/Documentation/ |
| D | objtool.txt | 99 the validity of its stack metadata. It enforces a set of rules on asm
205 callable function in order to analyze its stack metadata.
274 its ELF function annotation by changing ENDPROC to END, and instead
280 stack pointer in its output operand. On x86_64, this means adding
334 wasn't first restored to its original state.
|
| /tools/lib/perf/Documentation/ |
| D | libperf-counting.txt | 58 The `libperf_print` callback will receive any message with its debug level,
|
| D | libperf-sampling.txt | 65 The `libperf_print` callback will receive any message with its debug level,
|
| /tools/testing/memblock/ |
| D | README | 18 memory allocator is initialized at the build time, so the checks here reuse its
|
12