Masami wrote: > On Sun, 30 Aug 2026 19:07:43 +0800 (CST) > <[email protected]> wrote: > > > Hi Steven and Masami, > > > > This series adds two comm-based task filters for the function and > > function_graph tracers: > > > > set_ftrace_comm > > set_ftrace_notrace_comm > > > > Function tracing currently supports selecting tasks by PID. This makes > > it difficult to configure tracing before a service starts, because it > > does not have a PID yet. It is also inconvenient to keep tracing the > > same service across restarts, as its PID may change. This use case was > > suggested by Xuxin, a KSM reviewer. > > Thanks for the idea. I thought we can use `pidof` but it is for running > processes. >
Yes, exactly. The main use case is to configure tracing before the target task starts, when there is no PID for pidof to return. Thanks, Xuxin! :) > > > > The new filters match task comm names exactly. When both PID and comm > > include filters are active, a task must match both to be traced. A > > match in either the PID or comm notrace filter excludes the task. > > > > To avoid string matching in the function tracing fast path, the filters > > are evaluated when a task is scheduled in. The result is stored in the > > existing per-CPU cache used by PID filtering. Changing a filter refreshes > > the cached result for currently running tasks. If a task's comm changes, > > the new name is used the next time the task is scheduled in. > > OK, but can trace scheduler event (or add a new event) that we just convert > comm to PID when the comm is changed and add/remove it to pid filter? > If that works, we can also extend generic event trigger to set ftrace pid > filter. Using this allows you to add or remove processes as ftrace targets > at runtime—not only based on comm, but for other reasons as well. > (of course, setting per-cpu cache requires to kick a worker...) > > This will leak the pid via set_ftrace_pid, but that is good from the > monitoring point of view. > > Thank you, > Thank you for the suggestion! My understanding is that, instead of adding comm-specific function filters, we could add generic event-trigger actions that update the existing function PID filter. For example, the task_rename event already observes task comm changes. Conceptually, a user could configure something like: ftrace_pid_add:pid if newcomm == "foo" ftrace_pid_del:pid if oldcomm == "foo" && newcomm != "foo" The command names and syntax above are only examples. The PID field would be selected from the event record, so the same actions could be used with other events and filters, rather than being tied to comm or task_rename. I think the trigger actions could update the same PID list used by set_ftrace_pid. A PID added by a trigger would then become a normal set_ftrace_pid entry and would be visible when the file is read. The list would be shared state, without tracking whether an entry came from a user or a particular trigger. Removing a trigger would stop future updates but would not roll back PIDs that it had already added. Since an event trigger may run in a context where the PID list and per-CPU cache cannot be updated directly, the trigger could queue the operation to a worker. The worker would update the PID list and refresh the cached task-filter result. For the comm use case, a delete action on task_rename would remove a PID when the task no longer has the selected comm. A delete action on sched_process_exit could also remove stale PIDs when matching tasks exit. This would primarily support rules installed before a task starts or before the relevant event occurs. It would not discover tasks that already match when the trigger is installed unless they generate the event again. Does this shared PID-list and generic add/delete trigger model match what you had in mind? -- With Best Regards, Shengming
