> For latency-sensitive scenarios, such as industrial control, communications,
> or automotive, I think this tool is useful. And it may be better if it support
> showing whole delay of system by reading PSI, just like the first few lines of
> information output by the top command.
Another suggestion, we can provide a new command to control the display of
either the total memory delay for tasks or detailed memory delays. This approach
offers two benefits: first, it better aligns with PSI results; second, it offers choices
for users with different interests (e.g., some users may not have enabled or are
not concerned about swap delay). The implementation can follow the dynamic
command approach similar to top.
If it's OK to you, may send follow-up patch. For the initial patch:
> + * delaytop.c - task delay monitoring tool.
> + * This tool provides real-time monitoring and statistics of
> + * system, container, and task-level delays, including CPU,
Since the tool cover 'system' delay, we may say:
delaytop.c - system-wide delay monitoring tool.
> + * This tool provides real-time monitoring and statistics of
> + * system, container, and task-level delays, including CPU,
> + * memory, IO, and IRQ and delay accounting. It supports both
I am confused with the words 'and delay accouting', they are all
delays.
> + if (bind(fd, (struct sockaddr *) &local, sizeof(local)) < 0) {
> + close(fd);
> + return -1;
We better tell user what happend, and pelase check other code
that may also fail.
> + rc = recv(nl_sd, &resp, sizeof(resp), 0);
Please check if close(nl_sd) is called.
