| /tools/lib/perf/Documentation/ |
| D | libperf-counting.txt | 73 Once the setup is complete we start by defining specific events using the `struct perf_event_attr`.
97 In this case we will monitor current process, so we create threads map with single pid (0):
110 Now we create libperf's event list, which will serve as holder for the events we want:
121 We create libperf's events for the attributes we defined earlier and add them to the list:
156 so we need to enable the whole list explicitly (both events).
158 From this moment events are counting and we can do our workload.
160 When we are done we disable the events list.
171 Now we need to get the counts from events, following code iterates through the
|
| D | libperf-sampling.txt | 80 Once the setup is complete we start by defining cycles event using the `struct perf_event_attr`:
96 In this case we will monitor all the available CPUs:
107 Now we create libperf's event list, which will serve as holder for the cycles event:
118 We create libperf's event for the cycles attribute we defined earlier and add it to the list:
144 Once the events list is open, we can create memory maps AKA perf ring buffers:
156 so we need to enable the events list explicitly.
160 We will sleep for 3 seconds while the ring buffers get data from all CPUs, then we disable the even…
|
| /tools/perf/ |
| D | builtin-timechart.c | 410 struct wake_event *we = zalloc(sizeof(*we)); in sched_wakeup() local
412 if (!we) in sched_wakeup()
415 we->time = timestamp; in sched_wakeup()
416 we->waker = waker; in sched_wakeup()
417 we->backtrace = backtrace; in sched_wakeup()
420 we->waker = -1; in sched_wakeup()
422 we->wakee = wakee; in sched_wakeup()
423 we->next = tchart->wake_events; in sched_wakeup()
424 tchart->wake_events = we; in sched_wakeup()
425 p = find_create_pid(tchart, we->wakee); in sched_wakeup()
[all …]
|
| /tools/build/Documentation/ |
| D | Build.txt | 10 Unlike the kernel we don't have a single build object 'obj-y' list that where
11 we setup source objects, but we support more. This allows one 'Build' file to
49 Assume we have the following project structure:
129 It's possible to include special rule if needed (like we do for flex or bison
|
| /tools/perf/Documentation/ |
| D | perf-script-python.txt | 75 that, but first we need to record the data that will be processed by
76 that script. Theoretically, there are a couple of ways we could do
79 - we could enable every event under the tracing/events/syscalls
82 useful if we want to later use the guidance we get from the
86 - we can enable the sys_enter and/or sys_exit syscalls found under
91 For this script, we only need to know that a syscall was entered; we
92 don't care how it exited, so we'll use 'perf record' to record only
107 Once we have a perf.data file containing our data, we can use the -g
206 Of course, for this script, we're not interested in printing every
207 trace event, but rather aggregating it in a useful way. So we'll get
[all …]
|
| D | perf-c2c.txt | 168 For each cacheline in the 1) list we display following data:
208 For each offset in the 2) list we display following data:
301 to get this implemented, we got lots of early help from Arnaldo
|
| D | perf-stat.txt | 459 As displayed in the example above we can display 3 types of timings.
464 For workload sessions we also display time the workloads spent in
|
| /tools/memory-model/litmus-tests/ |
| D | MP+polockonce+poacquiresilsil.litmus | 8 * first spin_is_locked() returns false and the second true, we know that
|
| D | MP+polockmbonce+poacquiresilsil.litmus | 9 * returns false and the second true, we know that the smp_load_acquire()
|
| D | README | 216 smp_load_acquire(), so next is "Once". Thus far, we have "Rfi Once".
222 READ_ONCE(), we add another "Once" descriptor.
229 The remainder of P1() is similar to P0(), which means we add
231 P0()'s first access, which is WRITE_ONCE(), so we add "Fre Once".
|
| /tools/memory-model/Documentation/ |
| D | explanation.txt | 85 store instruction accessing the same location (we ignore complicating
170 unconditionally then we would instead have r1 = 0 and r2 = 1.)
281 The LKMM is defined largely in terms of cycles, as we will see.
321 Events in the LKMM can be linked by various relations, which we will
334 instructions are presented to a CPU's execution unit. Thus, we say
347 program order we need to explain. The LKMM was inspired by low-level
367 than ordinary memory accesses. Thanks to this usage, we can be certain
482 come earlier in program order. Symbolically, if we have R ->data X,
483 R ->addr X, or R ->ctrl X (where R is a read event), then we must also
672 just like with the rf relation, we distinguish between stores that
[all …]
|
| D | simple.txt | 89 With code locking, we use single-threaded code execution to guarantee
91 we can also achieve this by instead associating the lock with specific
95 inside a critical section, we ensure that the execution context that
|
| /tools/testing/selftests/arm64/signal/ |
| D | README | 21 tdescr overriding all the defaults we wish to change (as of now providing a
47 and verify if it is indeed GOOD or BAD (depending on what we were
|
| /tools/perf/tests/attr/ |
| D | README | 10 these files are checked for values we expect for command.
22 separate file. Besides 'struct perf_event_attr' values we also
|
| /tools/testing/selftests/media_tests/ |
| D | regression_test.txt | 36 test with possible device names. If we start with /dev/media0 for example,
|
| /tools/usb/usbip/ |
| D | COPYING | 21 When we speak of free software, we are referring to freedom, not
28 To protect your rights, we need to make restrictions that forbid
43 Also, for each author's protection and ours, we want to make certain
45 software. If the software is modified by someone else and passed on, we
53 program proprietary. To prevent this, we have made it clear that any
253 Software Foundation, write to the Free Software Foundation; we sometimes
|
| D | README | 165 driver. To export this device, we first mark the device as
|
| /tools/bpf/bpftool/bash-completion/ |
| D | bpftool | 136 # Retrieve type of the map that we are operating on.
830 # word i.e. we can now have UPDATE_FLAGS.
838 # word i.e. we can now have 'value'.
1038 # "id|pinned|tag|name" (we already checked for
1040 # we need attach flags for "attach" commamnd.
|
| /tools/testing/selftests/ftrace/ |
| D | README | 4 kernel. Since ftrace exports interfaces via the debugfs, we just need
|
| /tools/testing/selftests/futex/ |
| D | README | 55 problem as we intend to write multiple tests which collide in this namespace.
|
| /tools/testing/selftests/arm64/fp/ |
| D | README | 67 To try to reproduce the bugs that we have been observing, sve-stress
|
| /tools/perf/tests/ |
| D | make | 57 # we need some IS_(32/64) flag to make this generic
124 # Makefile because we detect clean target in Makefile.perf and
|
| /tools/virtio/virtio-trace/ |
| D | README | 38 To use this trace agent for virtio-trace, we need to prepare some virtio-serial
|
| /tools/objtool/Documentation/ |
| D | stack-validation.txt | 28 Why do we need stack metadata validation?
72 If we remove the frame pointer logic from cmdline_proc_show() by
|
| /tools/bpf/bpftool/Documentation/ |
| D | bpftool-map.rst | 222 entry-point program. Below is an example for this use case: we load a program
|