fc30ace0 | 23-Jun-2023 |
Donglin Peng <pengdonglin@sangfor.com.cn> |
tracing: Fix warnings when building htmldocs for function graph retval
When building htmldocs, the following warnings appear:
Documentation/trace/ftrace.rst:2797: WARNING: Literal block expected; n
tracing: Fix warnings when building htmldocs for function graph retval
When building htmldocs, the following warnings appear:
Documentation/trace/ftrace.rst:2797: WARNING: Literal block expected; none found. Documentation/trace/ftrace.rst:2816: WARNING: Literal block expected; none found.
So fix it.
Link: https://lore.kernel.org/all/20230623143517.19ffc6c0@canb.auug.org.au/ Link: https://lkml.kernel.org/r/20230623071728.25688-1-pengdonglin@sangfor.com.cn
Fixes: 21c094d3f8a6 ("tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex") Signed-off-by: Donglin Peng <pengdonglin@sangfor.com.cn> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
show more ...
|
e88ed227 | 06-Jun-2023 |
Daniel Bristot de Oliveira <bristot@kernel.org> |
tracing/timerlat: Add user-space interface
Going a step further, we propose a way to use any user-space workload as the task waiting for the timerlat timer. This is done via a per-CPU file named osn
tracing/timerlat: Add user-space interface
Going a step further, we propose a way to use any user-space workload as the task waiting for the timerlat timer. This is done via a per-CPU file named osnoise/cpu$id/timerlat_fd file.
The tracef_fd allows a task to open at a time. When a task reads the file, the timerlat timer is armed for future osnoise/timerlat_period_us time. When the timer fires, it prints the IRQ latency and wakes up the user-space thread waiting in the timerlat_fd.
The thread then starts to run, executes the timerlat measurement, prints the thread scheduling latency and returns to user-space.
When the thread rereads the timerlat_fd, the tracer will print the user-ret(urn) latency, which is an additional metric.
This additional metric is also traced by the tracer and can be used, for example of measuring the context switch overhead from kernel-to-user and user-to-kernel, or the response time for an arbitrary execution in user-space.
The tracer supports one thread per CPU, the thread must be pinned to the CPU, and it cannot migrate while holding the timerlat_fd. The reason is that the tracer is per CPU (nothing prohibits the tracer from allowing migrations in the future). The tracer monitors the migration of the thread and disables the tracer if detected.
The timerlat_fd is only available for opening/reading when timerlat tracer is enabled, and NO_OSNOISE_WORKLOAD is set.
The simplest way to activate this feature from user-space is:
-------------------------------- %< ----------------------------------- int main(void) { char buffer[1024]; int timerlat_fd; int retval; long cpu = 0; /* place in CPU 0 */ cpu_set_t set;
CPU_ZERO(&set); CPU_SET(cpu, &set);
if (sched_setaffinity(gettid(), sizeof(set), &set) == -1) return 1;
snprintf(buffer, sizeof(buffer), "/sys/kernel/tracing/osnoise/per_cpu/cpu%ld/timerlat_fd", cpu);
timerlat_fd = open(buffer, O_RDONLY); if (timerlat_fd < 0) { printf("error opening %s: %s\n", buffer, strerror(errno)); exit(1); }
for (;;) { retval = read(timerlat_fd, buffer, 1024); if (retval < 0) break; }
close(timerlat_fd); exit(0); } -------------------------------- >% -----------------------------------
When disabling timerlat, if there is a workload holding the timerlat_fd, the SIGKILL will be sent to the thread.
Link: https://lkml.kernel.org/r/69fe66a863d2792ff4c3a149bf9e32e26468bb3a.1686063934.git.bristot@kernel.org
Cc: Juri Lelli <juri.lelli@redhat.com> Cc: William White <chwhite@redhat.com> Cc: Daniel Bristot de Oliveira <bristot@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
show more ...
|
83f74441 | 11-Jun-2023 |
Jiri Olsa <jolsa@kernel.org> |
ftrace: Show all functions with addresses in available_filter_functions_addrs
Adding new available_filter_functions_addrs file that shows all available functions (same as available_filter_functions)
ftrace: Show all functions with addresses in available_filter_functions_addrs
Adding new available_filter_functions_addrs file that shows all available functions (same as available_filter_functions) together with addresses, like:
# cat available_filter_functions_addrs | head ffffffff81000770 __traceiter_initcall_level ffffffff810007c0 __traceiter_initcall_start ffffffff81000810 __traceiter_initcall_finish ffffffff81000860 trace_initcall_finish_cb ...
Note displayed address is the patch-site address and can differ from /proc/kallsyms address.
It's useful to have address avilable for traceable symbols, so we don't need to allways cross check kallsyms with available_filter_functions (or the other way around) and have all the data in single file.
For backwards compatibility reasons we can't change the existing available_filter_functions file output, but we need to add new file.
The problem is that we need to do 2 passes:
- through available_filter_functions and find out if the function is traceable - through /proc/kallsyms to get the address for traceable function
Having available_filter_functions symbols together with addresses allow us to skip the kallsyms step and we are ok with the address in available_filter_functions_addr not being the function entry, because kprobe_multi uses fprobe and that handles both entry and patch-site address properly.
We have 2 interfaces how to create kprobe_multi link:
a) passing symbols to kernel
1) user gathers symbols and need to ensure that they are trace-able -> pass through available_filter_functions file
2) kernel takes those symbols and translates them to addresses through kallsyms api
3) addresses are passed to fprobe/ftrace through:
register_fprobe_ips -> ftrace_set_filter_ips
b) passing addresses to kernel
1) user gathers symbols and needs to ensure that they are trace-able -> pass through available_filter_functions file
2) user takes those symbols and translates them to addresses through /proc/kallsyms
3) addresses are passed to the kernel and kernel calls:
register_fprobe_ips -> ftrace_set_filter_ips
The new available_filter_functions_addrs file helps us with option b), because we can make 'b 1' and 'b 2' in one step - while filtering traceable functions, we get the address directly.
Link: https://lore.kernel.org/linux-trace-kernel/20230611130029.1202298-1-jolsa@kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com> Tested-by: Jackie Liu <liuyun01@kylinos.cn> # x86 Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org> Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
show more ...
|
6373c463 | 21-Jun-2023 |
Yicong Yang <yangyicong@hisilicon.com> |
hwtracing: hisi_ptt: Export available filters through sysfs
The PTT can only filter the traced TLP headers by the Root Ports or the Requester ID of the Endpoint, which are located on the same PCIe c
hwtracing: hisi_ptt: Export available filters through sysfs
The PTT can only filter the traced TLP headers by the Root Ports or the Requester ID of the Endpoint, which are located on the same PCIe core of the PTT device. The filter value used is derived from the BDF number of the supported Root Port or the Endpoint. It's not friendly enough for the users since it requires the user to be familiar enough with the platform and calculate the filter value manually.
This patch export the available filters through sysfs. Each available filters is presented as an individual file with the name of the BDF number of the related PCIe device. The files are created under $(PTT PMU dir)/available_root_port_filters and $(PTT PMU dir)/available_requester_filters respectively. The filter value can be known by reading the related file.
Then the users can easily know the available filters for trace and get the filter values without calculating.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20230621092804.15120-4-yangyicong@huawei.com
show more ...
|
6ce2c04f | 02-May-2023 |
Steven Rostedt (Google) <rostedt@goodmis.org> |
ftrace: Add MODIFIED flag to show if IPMODIFY or direct was attached
If a function had ever had IPMODIFY or DIRECT attached to it, where this is how live kernel patching and BPF overrides work, mark
ftrace: Add MODIFIED flag to show if IPMODIFY or direct was attached
If a function had ever had IPMODIFY or DIRECT attached to it, where this is how live kernel patching and BPF overrides work, mark them and display an "M" in the enabled_functions and touched_functions files. This can be used for debugging. If a function had been modified and later there's a bug in the code related to that function, this can be used to know if the cause is possibly from a live kernel patch or a BPF program that changed the behavior of the code.
Also update the documentation on the enabled_functions and touched_functions output, as it was missing direct callers and CALL_OPS. And include this new modify attribute.
Link: https://lore.kernel.org/linux-trace-kernel/20230502213233.004e3ae4@gandalf.local.home
Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
show more ...
|
80a76994 | 28-Mar-2023 |
Steven Rostedt (Google) <rostedt@goodmis.org> |
tracing: Add "fields" option to show raw trace event fields
The hex, raw and bin formats come from the old PREEMPT_RT patch set latency tracer. That actually gave real alternatives to reading the as
tracing: Add "fields" option to show raw trace event fields
The hex, raw and bin formats come from the old PREEMPT_RT patch set latency tracer. That actually gave real alternatives to reading the ascii buffer. But they have started to bit rot and they do not give a good representation of the tracing data.
Add "fields" option that will read the trace event fields and parse the data from how the fields are defined:
With "fields" = 0 (default)
echo 1 > events/sched/sched_switch/enable cat trace <idle>-0 [003] d..2. 540.078653: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/3:1 next_pid=83 next_prio=120 kworker/3:1-83 [003] d..2. 540.078860: sched_switch: prev_comm=kworker/3:1 prev_pid=83 prev_prio=120 prev_state=I ==> next_comm=swapper/3 next_pid=0 next_prio=120 <idle>-0 [003] d..2. 540.206423: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=sshd next_pid=807 next_prio=120 sshd-807 [003] d..2. 540.206531: sched_switch: prev_comm=sshd prev_pid=807 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120 <idle>-0 [001] d..2. 540.206597: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120 kworker/u16:4-58 [001] d..2. 540.206617: sched_switch: prev_comm=kworker/u16:4 prev_pid=58 prev_prio=120 prev_state=I ==> next_comm=bash next_pid=830 next_prio=120 bash-830 [001] d..2. 540.206678: sched_switch: prev_comm=bash prev_pid=830 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120 kworker/u16:4-58 [001] d..2. 540.206696: sched_switch: prev_comm=kworker/u16:4 prev_pid=58 prev_prio=120 prev_state=I ==> next_comm=bash next_pid=830 next_prio=120 bash-830 [001] d..2. 540.206713: sched_switch: prev_comm=bash prev_pid=830 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120
echo 1 > options/fields <...>-998 [002] d..2. 538.643732: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/2 prev_state=0x20 (32) prev_prio=0x78 (120) prev_pid=0x3e6 (998) prev_comm=trace-cmd <idle>-0 [001] d..2. 538.643806: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x0 (0) prev_comm=swapper/1 bash-830 [001] d..2. 538.644106: sched_switch: next_prio=0x78 (120) next_pid=0x3a (58) next_comm=kworker/u16:4 prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash kworker/u16:4-58 [001] d..2. 538.644130: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x80 (128) prev_prio=0x78 (120) prev_pid=0x3a (58) prev_comm=kworker/u16:4 bash-830 [001] d..2. 538.644180: sched_switch: next_prio=0x78 (120) next_pid=0x3a (58) next_comm=kworker/u16:4 prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash kworker/u16:4-58 [001] d..2. 538.644185: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x80 (128) prev_prio=0x78 (120) prev_pid=0x3a (58) prev_comm=kworker/u16:4 bash-830 [001] d..2. 538.644204: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/1 prev_state=0x1 (1) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash <idle>-0 [003] d..2. 538.644211: sched_switch: next_prio=0x78 (120) next_pid=0x327 (807) next_comm=sshd prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x0 (0) prev_comm=swapper/3 sshd-807 [003] d..2. 538.644340: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/3 prev_state=0x1 (1) prev_prio=0x78 (120) prev_pid=0x327 (807) prev_comm=sshd
It traces the data safely without using the trace print formatting.
Link: https://lore.kernel.org/linux-trace-kernel/20230328145156.497651be@gandalf.local.home
Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Beau Belgrave <beaub@linux.microsoft.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
show more ...
|
70515962 | 20-Jan-2023 |
Bagas Sanjaya <bagasdotme@gmail.com> |
Documentation: coresight: tpdm: Add dummy comment after sysfs list
kernel test robot reported htmldocs warning:
Documentation/trace/coresight/coresight-tpdm.rst:43: WARNING: Document may not end wi
Documentation: coresight: tpdm: Add dummy comment after sysfs list
kernel test robot reported htmldocs warning:
Documentation/trace/coresight/coresight-tpdm.rst:43: WARNING: Document may not end with a transition.
Since there is no more documentation left for TPDM, fix the warning by adding dummy comment, thus creating the required text transition.
Link: https://lore.kernel.org/linux-doc/202301210955.zYxDrLgv-lkp@intel.com/ Fixes: 758d638667d474 ("Documentation: trace: Add documentation for TPDM and TPDA") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20230121040015.28139-3-bagasdotme@gmail.com
show more ...
|
ba0f3ae6 | 20-Jan-2023 |
Bagas Sanjaya <bagasdotme@gmail.com> |
Documentation: coresight: Extend title heading syntax in TPDM and TPDA documentation
kernel test robot reported htmldocs warnings:
Documentation/trace/coresight/coresight-tpda.rst:3: WARNING: Title
Documentation: coresight: Extend title heading syntax in TPDM and TPDA documentation
kernel test robot reported htmldocs warnings:
Documentation/trace/coresight/coresight-tpda.rst:3: WARNING: Title overline too short. Documentation/trace/coresight/coresight-tpdm.rst:3: WARNING: Title overline too short.
Extend title heading syntax (overline and underline) to match title text to fix these warnings.
While at it, trim unneeded period in the title text.
Link: https://lore.kernel.org/linux-doc/202301210955.zYxDrLgv-lkp@intel.com/ Fixes: 758d638667d474 ("Documentation: trace: Add documentation for TPDM and TPDA") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20230121040015.28139-2-bagasdotme@gmail.com
show more ...
|