Lines Matching refs:the
6 per-process statistics from the kernel to userspace.
8 Taskstats was designed for the following benefits:
17 "pid", "tid" and "task" are used interchangeably and refer to the standard
18 Linux task defined by struct task_struct. per-pid stats are the same as
21 "tgid", "process" and "thread group" are used interchangeably and refer to the
22 tasks that share an mm_struct i.e. the traditional Unix process. Despite the
23 use of tgid, there is no special treatment for the task that is thread group
31 The response contains statistics for a task (if pid is specified) or the sum of
32 statistics for all tasks of the process (if tgid is specified).
34 To obtain statistics for tasks which are exiting, the userspace listener
36 one of the cpus in the cpumask, its per-pid statistics are sent to the
37 registered listener. Using cpumasks allows the data received by one listener
38 to be limited and assists in flow control over the netlink interface and is
41 If the exiting task is the last thread exiting its thread group,
42 an additional record containing the per-tgid stats is also sent to userspace.
43 The latter contains the sum of per-pid stats for all threads in the thread
46 getdelays.c is a simple utility demonstrating usage of the taskstats interface
49 write the data received to a file and do basic flow control by increasing
57 To avoid this documentation becoming obsolete as the interface evolves, only
58 an outline of the current version is given. taskstats.h always overrides the
61 struct taskstats is the common accounting structure for both per-pid and
63 that is added to the kernel. The fields and their semantics are defined in the
67 to the NETLINK_GENERIC family and using the netlink attributes interface.
68 The messages are in the format
75 The taskstats payload is one of the following three kinds:
79 containing a u32 pid or tgid in the attribute payload. The pid/tgid denotes
80 the task/process for which userspace wants statistics.
84 TASKSTATS_CMD_ATTR_REGISTER/DEREGISTER_CPUMASK and contain a cpumask in the
87 the cpumask would be "1-3,5,7-8". If userspace forgets to deregister interest
88 in cpus before closing the listening socket, the kernel cleans up its interest
89 set over time. However, for the sake of efficiency, an explicit deregistration
92 2. Response for a command: sent from the kernel in response to a userspace
98 b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
105 series of attributes of the following type:
109 c) TASKSTATS_TYPE_STATS: contains the exiting task's per-pid stats
112 f) TASKSTATS_TYPE_STATS: contains the per-tgid stats for exiting task's process
123 However, maintaining per-process, in addition to per-task stats, within the
124 kernel has space and time overheads. To address this, the taskstats code
126 When the last task of a process exits, the process level data accumulated also
127 gets sent to userspace (along with the per-task data).
129 When a user queries to get per-tgid data, the sum of all other live threads in
130 the group is added up and added to the accumulated total for previously exited
131 threads of the same thread group.
136 There are two ways to extend the taskstats interface to export more
137 per-task/process stats as patches to collect them get added to the kernel
140 1. Adding more fields to the end of the existing struct taskstats. Backward
141 compatibility is ensured by the version number within the
142 structure. Userspace will use only the fields of the struct that correspond
143 to the version its using.
145 2. Defining separate statistic structs and using the netlink attributes
148 understand (because it is using an older version of the interface).
152 overhead. If only a few fields need to be added, then 1. is the preferable
153 path since the kernel and userspace don't need to incur the overhead of
154 processing new netlink attributes. But if the new fields expand the existing
157 extending the attributes structure would be worthwhile.
162 When the rate of task exits becomes large, a listener may not be able to keep
163 up with the kernel's rate of sending per-tid/tgid exit data leading to data
164 loss. This possibility gets compounded when the taskstats structure gets
165 extended and the number of cpus grows large.
167 To avoid losing statistics, userspace should do one or more of the following:
169 - increase the receive buffer sizes for the netlink sockets opened by
172 - create more listeners and reduce the number of cpus being listened to by
173 each listener. In the extreme case, there could be one listener for each cpu.
174 Users may also consider setting the cpu affinity of the listener to the subset
177 Despite these measures, if the userspace receives ENOBUFS error messages
178 indicated overflow of receive buffers, it should take measures to handle the