- 08 Sep, 2021 8 commits
-
-
Masami Hiramatsu authored
Show whole test command instead of only the 3rd argument. This will clear to show what will be actually tested by each test case. Link: https://lkml.kernel.org/r/163077088607.222577.14786016266462495017.stgit@devnote2Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Julio Faracco authored
The function `xbc_show_list should` handle the keys during the composition. Even the errors returned by the compose function. Instead of removing the `ret` variable, it should save the value and show the exact error. This missing variable is causing a compilation issue also. Link: https://lkml.kernel.org/r/163077087861.222577.12884543474750968146.stgit@devnote2 Fixes: e5efaeb8 ("bootconfig: Support mixing a value and subkeys under a key") Signed-off-by:
Julio Faracco <jcfaracco@gmail.com> Acked-by:
-
Masami Hiramatsu authored
Since tracing_on indicates only "1" (default) or "0", ftrace2bconf.sh only need to check the value is "0". Link: https://lkml.kernel.org/r/163077087144.222577.6888011847727968737.stgit@devnote2 Fixes: 55ed4560 ("tools/bootconfig: Add tracing_on support to helper scripts") Signed-off-by:
-
Masami Hiramatsu authored
Add a section to describe how to use the bootconfig for specifying kernel and init parameters. This is an important section because it is the reason why this document is under the admin-guide. Link: https://lkml.kernel.org/r/163077086399.222577.5881779375643977991.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Reorder the init parameters from bootconfig and kernel cmdline so that the kernel cmdline always be the last part of the parameters as below. " -- "[bootconfig init params][cmdline init params] This change will help us to prevent that bootconfig init params overwrite the init params which user gives in the command line. Link: https://lkml.kernel.org/r/163077085675.222577.5665176468023636160.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Since the bootconfig is used only in the init functions, it doesn't need to keep the data after boot. Free it when the init memory is removed. Link: https://lkml.kernel.org/r/163077084958.222577.5924961258513004428.stgit@devnote2Signed-off-by:
-
Qiang.Zhang authored
When start_kthread() return error, the cpus_read_unlock() need to be called. Link: https://lkml.kernel.org/r/20210831022919.27630-1-qiang.zhang@windriver.com Cc: <stable@vger.kernel.org> Fixes: c8895e27 ("trace/osnoise: Support hotplug operations") Acked-by:
Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by:
Qiang.Zhang <qiang.zhang@windriver.com> Signed-off-by:
-
Dan Carpenter authored
There are two bugs in this code. First, if the kzalloc() fails it leads to a NULL dereference of "ep" on the next line. Second, if the alloc_event_probe() function returns an error then it leads to an error pointer dereference in the caller. Link: https://lkml.kernel.org/r/20210824115150.GI31143@kili Fixes: 7491e2c4 ("tracing: Add a probe that attaches to trace events") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 03 Sep, 2021 1 commit
-
-
Thomas Gleixner authored
migrate_disable() forbids task migration to another CPU. It is available since v5.11 and has already users such as highmem or BPF. It is useful to observe this task state in tracing which already has other states like the preemption counter. Instead of adding the migrate disable counter as a new entry to struct trace_entry, which would extend the whole struct by four bytes, it is squashed into the preempt-disable counter. The lower four bits represent the preemption counter, the upper four bits represent the migrate disable counter. Both counter shouldn't exceed 15 but if they do, there is a safety net which caps the value at 15. Add the migrate-disable counter to the trace entry so it shows up in the trace. Due to the users mentioned above, it is already possible to observe it: | bash-1108 [000] ...21 73.950578: rss_stat: mm_id=2213312838 curr=0 type=MM_ANONPAGES size=8192B | bash-1108 [000] d..31 73.951222: irq_disable: caller=flush_tlb_mm_range+0x115/0x130 parent=ptep_clear_flush+0x42/0x50 | bash-1108 [000] d..31 73.951222: tlb_flush: pages:1 reason:local mm shootdown (3) The last value is the migrate-disable counter. Things that popped up: - trace_print_lat_context() does not print the migrate counter. Not sure if it should. It is used in "verbose" mode and uses 8 digits and I'm not sure ther is something processing the value. - trace_define_common_fields() now defines a different variable. This probably breaks things. No ide what to do in order to preserve the old behaviour. Since this is used as a filter it should be split somehow to be able to match both nibbles here. Link: https://lkml.kernel.org/r/20210810132625.ylssabmsrkygokuv@linutronix.deSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> [bigeasy: patch description.] Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> [ SDR: Removed change to common_preempt_count field name ] Signed-off-by:
-
- 24 Aug, 2021 1 commit
-
-
Steven Rostedt (VMware) authored
The addition of the buckets conversion for the histogram code, updated the documentation table of available conversions, but did not update the format to accommodate the extra size needed to cover the description. Link: https://lkml.kernel.org/r/20210823100007.71ce2ba9@oasis.local.homeReported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Tested-by:
-
- 21 Aug, 2021 4 commits
-
-
Steven Rostedt (VMware) authored
Add a selftest that makes sure that eprobes and kprobes can not be created with the same group and name as existing events. Link: https://lore.kernel.org/linux-kselftest/20210819152825.715290342@goodmis.org/ Link: https://lkml.kernel.org/r/20210820204742.653288346@goodmis.org Cc: "Tzvetomir Stoyanov" <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Acked-by:
-
Steven Rostedt (VMware) authored
Add a test to test event probes, by creating a synthetic event across sys_enter_openat and sys_exit_openat that passes the filename pointer from the enter of the system call to the exit, and then add an event probe to the synthetic event to make sure that the file name is seen. Link: https://lore.kernel.org/linux-kselftest/20210819152825.526931866@goodmis.org/ Link: https://lkml.kernel.org/r/20210820204742.463259900@goodmis.org Cc: "Tzvetomir Stoyanov" <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Acked-by:
-
Steven Rostedt (VMware) authored
Add a test case that adds an event probe, makes sure that it works, and then removes it. Link: https://lore.kernel.org/linux-kselftest/20210819152825.526931866@goodmis.org/ Link: https://lkml.kernel.org/r/20210820204742.274591200@goodmis.org Cc: "Tzvetomir Stoyanov" <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Acked-by:
-
Steven Rostedt (VMware) authored
The selftest for ftrace checks some features by checking if the README has text that states the feature is supported by that kernel. Unfortunately, this check gives false positives because it many not be checked if there's spaces in the string to check. This is due to the compare between the required variable with the ":README" string stripped, because neither has quotes around them. Link: https://lkml.kernel.org/r/20210820204742.087177341@goodmis.org Cc: "Tzvetomir Stoyanov" <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Cc: stable@vger.kernel.org Fixes: 1b8eec51 ("selftests/ftrace: Support ":README" suffix for requires") Acked-by:
-
- 20 Aug, 2021 2 commits
-
-
Steven Rostedt (VMware) authored
Add a function to remove all dynamic events from the tracing directory. It requires a loop as some of the dynamic events may depend on others being removed first. Also add a safety that prevents it from looping infinitely due to a bug where an event never gets removed. Link: https://lkml.kernel.org/r/20210819152825.348941368@goodmis.org Cc: "Tzvetomir Stoyanov" <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Acked-by:
-
Tzvetomir Stoyanov (VMware) authored
A new dynamic event is introduced: event probe. The event is attached to an existing tracepoint and uses its fields as arguments. The user can specify custom format string of the new event, select what tracepoint arguments will be printed and how to print them. An event probe is created by writing configuration string in 'dynamic_events' ftrace file: e[:[SNAME/]ENAME] SYSTEM/EVENT [FETCHARGS] - Set an event probe -:SNAME/ENAME - Delete an event probe Where: SNAME - System name, if omitted 'eprobes' is used. ENAME - Name of the new event in SNAME, if omitted the SYSTEM_EVENT is used. SYSTEM - Name of the system, where the tracepoint is defined, mandatory. EVENT - Name of the tracepoint event in SYSTEM, mandatory. FETCHARGS - Arguments: <name>=$<field>[:TYPE] - Fetch given filed of the tracepoint and print it as given TYPE with given name. Supported types are: (u8/u16/u32/u64/s8/s16/s32/s64), basic type (x8/x16/x32/x64), hexadecimal types "string", "ustring" and bitfield. Example, attach an event probe on openat system call and print name of the file that will be opened: echo "e:esys/eopen syscalls/sys_enter_openat file=\$filename:string" >> dynamic_events A new dynamic event is created in events/esys/eopen/ directory. It can be deleted with: echo "-:esys/eopen" >> dynamic_events Filters, triggers and histograms can be attached to the new event, it can be matched in synthetic events. There is one limitation - an event probe can not be attached to kprobe, uprobe or another event probe. Link: https://lkml.kernel.org/r/20210812145805.2292326-1-tz.stoyanov@gmail.com Link: https://lkml.kernel.org/r/20210819152825.142428383@goodmis.orgAcked-by:Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com> Signed-off-by:
-
- 19 Aug, 2021 3 commits
-
-
Masami Hiramatsu authored
Since kprobe_events and uprobe_events only check whether the other same-type probe event has the same name or not, if the user gives the same name of the existing tracepoint event (or the other type of probe events), it silently fails to create the tracefs entry (but registered.) as below. /sys/kernel/tracing # ls events/task/task_rename enable filter format hist id trigger /sys/kernel/tracing # echo p:task/task_rename vfs_read >> kprobe_events [ 113.048508] Could not create tracefs 'task_rename' directory /sys/kernel/tracing # cat kprobe_events p:task/task_rename vfs_read To fix this issue, check whether the existing events have the same name or not in trace_probe_register_event_call(). If exists, it rejects to register the new event. Link: https://lkml.kernel.org/r/162936876189.187130.17558311387542061930.stgit@devnote2Signed-off-by:
-
Steven Rostedt (VMware) authored
In preparation to allow event probes to use the process_fetch_insn() callback in trace_probe_tmpl.h, change the data passed to it from a pointer to pt_regs, as the event probe will not be using regs, and make it a void pointer instead. Update the process_fetch_insn() callers for kprobe and uprobe events to have the regs defined in the function and just typecast the void pointer parameter. Link: https://lkml.kernel.org/r/20210819041842.291622924@goodmis.orgAcked-by:
-
Steven Rostedt (VMware) authored
Instead of a boolean "is_return" have traceprobe_set_print_fmt() take a type (currently just PROBE_PRINT_NORMAL and PROBE_PRINT_RETURN). This will simplify adding different types. For example, the development of the event_probe, will need its own type as it prints an event, and not an IP. Link: https://lkml.kernel.org/r/20210819041842.104626301@goodmis.orgAcked-by:
-
- 18 Aug, 2021 5 commits
-
-
Steven Rostedt (VMware) authored
Remove SIZEOF_TRACE_KPROBE() and SIZEOF_TRACE_UPROBE() and use struct_size() as that's what it is made for. No need to have custom macros. Especially since struct_size() has some extra memory checks for correctness. Link: https://lkml.kernel.org/r/20210817035027.795000217@goodmis.orgAcked-by:
-
Steven Rostedt (VMware) authored
Kprobe and uprobe events can add a "system" to the events that are created via the kprobe_events and uprobe_events files respectively. If they do not include a "system" in the name, then the default "kprobes" or "uprobes" is used. The current notation to specify a system for one of these probe events is to add a '/' delimiter in the name, where the content before the '/' will be the system to use, and the content after will be the event name. echo 'p:my_system/my_event' > kprobe_events But this is inconsistent with the way histogram triggers separate their system / event names. The histogram triggers use a '.' delimiter, which can be confusing. To allow this to be more consistent, as well as keep backward compatibility, allow the kprobe and uprobe events to denote a system name with either a '/' or a '.'. That is: echo 'p:my_system/my_event' > kprobe_events is equivalent to: echo 'p:my_system.my_event' > kprobe_events Link: https://lore.kernel.org/linux-trace-devel/20210813004448.51c7de69ce432d338f4d226b@kernel.org/ Link: https://lkml.kernel.org/r/20210817035027.580493202@goodmis.orgSuggested-by:
-
Steven Rostedt (VMware) authored
The two places that call traceprobe_parse_probe_arg() allocate a temporary buffer to copy the argv[i] into, because argv[i] is constant and the traceprobe_parse_probe_arg() will modify it to do the parsing. These two places allocate this buffer and then free it right after calling this function, leaving the onus of this allocation to the caller. As there's about to be a third user of this function that will have to do the same thing, instead of having the caller allocate the temporary buffer, simply move that allocation into the traceprobe_parse_probe_arg() itself, which will simplify the code of the callers. Link: https://lkml.kernel.org/r/20210817035027.385422828@goodmis.orgAcked-by:
-
Steven Rostedt (VMware) authored
As dynamic events are not created by modules, if something is attached to one, calling "try_module_get()" on its "mod" field, is not going to keep the dynamic event from going away. Since dynamic events do not need the "mod" pointer of the event structure, make a union out of it in order to save memory (there's one structure for each of the thousand+ events in the kernel), and have any event with the DYNAMIC flag set to use a ref counter instead. Link: https://lore.kernel.org/linux-trace-devel/20210813004448.51c7de69ce432d338f4d226b@kernel.org/ Link: https://lkml.kernel.org/r/20210817035027.174869074@goodmis.orgSuggested-by:
-
Steven Rostedt (VMware) authored
To differentiate between static and dynamic events, add a new flag DYNAMIC to the event flags that all dynamic events have set. This will allow to differentiate when attaching to a dynamic event from a static event. Static events have a mod pointer that references the module they were created in (or NULL for core kernel). This can be incremented when the event has something attached to it. But there exists no such mechanism for dynamic events. This is dangerous as the dynamic events may now disappear without the "attachment" knowing that it no longer exists. To enforce the dynamic flag, change dyn_event_add() to pass the event that is being created such that it can set the DYNAMIC flag of the event. This helps make sure that no location that creates a dynamic event misses setting this flag. Link: https://lore.kernel.org/linux-trace-devel/20210813004448.51c7de69ce432d338f4d226b@kernel.org/ Link: https://lkml.kernel.org/r/20210817035026.936958254@goodmis.orgSuggested-by:
-
- 17 Aug, 2021 1 commit
-
-
Sebastian Andrzej Siewior authored
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock(). Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged. Link: https://lkml.kernel.org/r/20210803141621.780504-37-bigeasy@linutronix.de Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Acked-by:
-
- 16 Aug, 2021 15 commits
-
-
Steven Rostedt (VMware) authored
The "latency" tracers have some different requirements than normal tracing, and also includes Daniel as a maintainer. Add a section in the MAINTAINERS file to help direct patches and bug reports to these tracers to the right people. Signed-off-by: -
zhaoxiao authored
Fix function name in tracepoint.c kernel-doc comment to remove a warning found by clang_w1. kernel/tracepoint.c:589: warning: expecting prototype for register_tracepoint_notifier(). Prototype was for register_tracepoint_module_notifier() instead kernel/tracepoint.c:613: warning: expecting prototype for unregister_tracepoint_notifier(). Prototype was for unregister_tracepoint_module_notifier() instead Link: https://lkml.kernel.org/r/20210816052430.16539-1-zhaoxiao@uniontech.comAcked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
zhaoxiao <zhaoxiao@uniontech.com> Signed-off-by:
-
Masami Hiramatsu authored
Update ktest example for the boot-time tracing with histogram options. Note that since the histogram option uses "trace()" action instead of "EVENT()", this updates the matching pattern too. Link: https://lkml.kernel.org/r/162856130208.203126.4458319094852152589.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Use per-group/all enable option instead of ftrace.events option. This will make the bootconfig file more readable. Link: https://lkml.kernel.org/r/162856129436.203126.12462564671412940618.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Add histogram syntax support to bconf2ftrace.sh script. Link: https://lkml.kernel.org/r/162856128672.203126.8240335908303312607.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Add group or all event enabling syntax support to bconf2ftrace.sh. User can pass a bootconfig file which includes ftrace[.instance.INSTANCE].event.enable and ftrace[.instance.INSTANCE].event.GROUP.enable correctly. Link: https://lkml.kernel.org/r/162856127850.203126.16694505101982548237.stgit@devnote2Signed-off-by: -
Masami Hiramatsu authored
Add the documentation about histogram syntax in boot-time tracing. This will allow user to write the histogram setting in a structured parameters. Link: https://lkml.kernel.org/r/162856127129.203126.15551542847575916525.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Since trigger_process_regex() modifies given trigger actions while parsing, the error message couldn't show what command was passed to the trigger_process_regex() when it returns an error. To fix that, show the backed up trigger action command instead of parsed buffer. Link: https://lkml.kernel.org/r/162856126413.203126.9465564928450701424.stgit@devnote2Signed-off-by:
-
Masami Hiramatsu authored
Add multiple histograms support for each event. This allows user to set multiple histograms to an event. ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist[.N] { ... } The 'N' is a digit started string and it can be omitted for the default histogram. For example, multiple hist triggers example in the Documentation/trace/histogram.rst can be written as below; ftrace.event.net.netif_receive_skb.hist { 1 { keys = skbaddr.hex values = len filter = len < 0 } 2 { keys = skbaddr.hex values = len filter = len > 4096 } 3 { keys = skbaddr.hex values = len filter = len == 256 } 4 { keys = skbaddr.hex values = len } 5 { keys = len values = common_preempt_count } } Link: https://lkml.kernel.org/r/162856125628.203126.15846930277378572120.stgit@devnote2Signed-off-by: -
Masami Hiramatsu authored
Support multiple handlers for per-event histogram in boot-time tracing. Since the histogram can register multiple same handler-actions with different parameters, this expands the syntax to support such cases. With this update, the 'onmax', 'onchange' and 'onmatch' handler subkeys under per-event histogram option will take a number subkeys optionally as below. (see [.N]) ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist { onmax|onchange[.N] { var = <VAR>; <ACTION> [= <PARAM>] } onmatch[.N] { event = <EVENT>; <ACTION> [= <PARAM>] } } The 'N' must be a digit (or digit started word). Thus user can add several handler-actions to the histogram, for example, ftrace.event.SOMEGROUP.SOMEEVENT.hist { keys = SOME_ID; lat = common_timestamp.usecs-$ts0 onmatch.1 { event = GROUP1.STARTEVENT1 trace = latency_event, SOME_ID, $lat } onmatch.2 { event = GROUP2.STARTEVENT2 trace = latency_event, SOME_ID, $lat } } Then, it can trace the elapsed time from GROUP1.STARTEVENT1 to SOMEGROUP.SOMEEVENT, and from GROUP2.STARTEVENT2 to SOMEGROUP.SOMEEVENT with SOME_ID key. Link: https://lkml.kernel.org/r/162856124905.203126.14913731908137885922.stgit@devnote2Signed-off-by: -
Masami Hiramatsu authored
Add a hist-trigger action syntax support to boot-time tracing. Currently, boot-time tracing supports per-event actions as option strings. However, for the histogram action, it has a special syntax and usually needs a long action definition. To make it readable and fit to the bootconfig syntax, this introduces a new options for histogram. Here are the histogram action options for boot-time tracing. ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist { keys = <KEY>[,...] values = <VAL>[,...] sort = <SORT-KEY>[,...] size = <ENTRIES> name = <HISTNAME> var { <VAR> = <EXPR> ... } pause|continue|clear onmax|onchange { var = <VAR>; <ACTION> [= <PARAM>] } onmatch { event = <EVENT>; <ACTION> [= <PARAM>] } filter = <FILTER> } Where <ACTION> is one of below; trace = <EVENT>, <ARG1>[, ...] save = <ARG1>[, ...] snapshot Link: https://lkml.kernel.org/r/162856124106.203126.10501871028479029087.stgit@devnote2Signed-off-by: -
Huang Shijie authored
It should be @prev_pid, not @prev_prid. Link: https://lkml.kernel.org/r/20210802140234.5383-1-shijie@os.amperecomputing.comSigned-off-by:
Huang Shijie <shijie@os.amperecomputing.com> Signed-off-by:
-
Masahiro Yamada authored
Make architectures select TRACE_IRQFLAGS_SUPPORT instead of having many defines. Link: https://lkml.kernel.org/r/20210731052233.4703-2-masahiroy@kernel.orgAcked-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> #arch/arc Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Masahiro Yamada authored
The entire FTRACE block is surrounded by 'if TRACING_SUPPORT' ... 'endif'. Using 'depends on' is a simpler way to guard FTRACE. Link: https://lkml.kernel.org/r/20210731052233.4703-1-masahiroy@kernel.orgSigned-off-by:
-
Steven Rostedt (VMware) authored
Allow common_pid.execname to be saved in a variable in one histogram to be passed to another histogram that can pass it as a parameter to a synthetic event. ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs:arg2=common_pid.execname' \ > events/sched/sched_waking/trigger ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1,exec=$arg2'\ ':onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,$exec)' \ > events/sched/sched_switch/trigger The above is a wake up latency synthetic event setup that passes the execname of the common_pid that woke the task to the scheduling of that task, which triggers a synthetic event that passes the original execname as a parameter to display it. ># echo 1 > events/synthetic/enable ># cat trace <idle>-0 [006] d..4 186.863801: wakeup_lat: pid=1306 delta=65 wake_comm=kworker/u16:3 <idle>-0 [000] d..4 186.863858: wakeup_lat: pid=163 delta=27 wake_comm=<idle> <idle>-0 [001] d..4 186.863903: wakeup_lat: pid=1307 delta=36 wake_comm=kworker/u16:4 <idle>-0 [000] d..4 186.863927: wakeup_lat: pid=163 delta=5 wake_comm=<idle> <idle>-0 [006] d..4 186.863957: wakeup_lat: pid=1306 delta=24 wake_comm=kworker/u16:3 sshd-1306 [006] d..4 186.864051: wakeup_lat: pid=61 delta=62 wake_comm=<idle> <idle>-0 [000] d..4 186.965030: wakeup_lat: pid=609 delta=18 wake_comm=<idle> <idle>-0 [006] d..4 186.987582: wakeup_lat: pid=1306 delta=65 wake_comm=kworker/u16:3 <idle>-0 [000] d..4 186.987639: wakeup_lat: pid=163 delta=27 wake_comm=<idle> Link: https://lkml.kernel.org/r/20210722142837.458596338@goodmis.orgReviewed-by:Tom Zanussi <zanussi@kernel.org> Reviewed-by:
-
