kernel/git/stable/linux.git/tools/accounting, branch master

tools/accounting: fix macro typos in getdelays

2026-08-04T04:10:17+00:00

Correct the spelling of PRINT_FILED_DELAY and PRINT_FILED_DELAY_WITH_TS to PRINT_FIELD_DELAY and PRINT_FIELD_DELAY_WITH_TS respectively. This resolves typo naming errors across the macro definitions and their matching inside print_delayacct(). Link: https://lore.kernel.org/20260716141545.1292951-1-shivanksharma2376543@gmail.com Signed-off-by: Shivank Sharma Cc: Fan Yu Cc: Wang Yaxin Signed-off-by: Andrew Morton

tools/accounting/delaytop.c: fix typo in PSI header string

2026-08-04T04:10:08+00:00

Link: https://lore.kernel.org/20260701011153.93426-1-sarasena.adr@gmail.com Signed-off-by: Sara Sena Cc: Fan Yu Cc: Wang Yaxin Signed-off-by: Andrew Morton

tools/accounting/getdelays: fix -Wformat-truncation warning in format_timespec

2026-05-29T04:24:40+00:00

Reproduce with GCC 13.3.0: $ cd tools/accounting $ make This emits: getdelays.c: In function `format_timespec': getdelays.c:218:67: warning: `:' directive output may be truncated writing 1 byte into a region of size between 0 and 16 [-Wformat-truncation=] 218 | snprintf(buffer, sizeof(buffer), "%04d-%02d-%02dT%02d:%02d:%02d", | getdelays.c:218:9: note: `snprintf' output between 20 and 72 bytes into a destination of size 32 The problem is that %04d and %02d specify minimum field widths only. GCC cannot prove that formatting tm_year + 1900 and the other struct tm fields will always fit in the fixed 32-byte buffer, so it warns about possible truncation. Fix this by replacing the manual snprintf() formatting with strftime("%Y-%m-%dT%H:%M:%S", ...). That matches the data we already have in struct tm, keeps the intended timestamp format, and avoids the warning when building tools/accounting with GCC. Link: https://lore.kernel.org/87d9723e0b59d816ee2e4bd7cddd58a54c6c9f91.1776956545.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen Cc: Fan Yu Cc: Wang Yaxin Signed-off-by: Andrew Morton

tools/accounting: handle truncated taskstats netlink messages

2026-04-15T09:15:02+00:00

procacct and getdelays use a fixed receive buffer for taskstats generic netlink messages. A multi-threaded process exit can emit a single PID+TGID notification large enough to exceed that buffer on newer kernels. Switch to recvmsg() so MSG_TRUNC is detected explicitly, increase the message buffer size, and report truncated datagrams clearly instead of misparsing them as fatal netlink errors. Also print the taskstats version in debug output to make version mismatches easier to diagnose while inspecting taskstats traffic. Link: https://lkml.kernel.org/r/520308bb4cbbaf8dc2c7296b5f60f11e12fb30a5.1774810498.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen Cc: Balbir Singh Cc: Dr. Thomas Orgis Cc: Fan Yu Cc: Wang Yaxin Cc: Signed-off-by: Andrew Morton

tools/getdelays: use the static UAPI headers from tools/include/uapi

2026-03-28T04:19:43+00:00

The include directory ../../usr/include is only present if an in-tree kernel build with CONFIG_HEADERS_INSTALL was done before. Otherwise the system UAPI headers are used, which most likely are not the most recent ones. To make sure to always have access to up-to-date UAPI headers, use the static copy in tools/include/uapi. Link: https://lkml.kernel.org/r/20260307-accounting-taskstats-h-v1-2-0b75915c6ce5@weissschuh.net Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202603062103.Z5fecwZD-lkp@intel.com/ Signed-off-by: Thomas Weißschuh Cc: Arnd Bergmann Cc: Balbir Singh Cc: Jiang Kun Cc: Wang Yaxin Cc: xu xin Cc: Yang Yang Signed-off-by: Andrew Morton

delayacct: fix build regression on accounting tool

2026-02-12T23:45:56+00:00

The accounting tool was modified for the original ABI using a custom 'timespec64' type in linux/taskstats.h, which I changed to use the regular __kernel_timespec type, causing a build failure: getdelays.c:202:45: warning: 'struct timespec64' declared inside parameter list will not be visible outside of this definition or declaration 202 | static const char *format_timespec64(struct timespec64 *ts) | ^~~~~~~~~~ Change the tool to match the updated header. Link: https://lkml.kernel.org/r/20260210103427.2984963-1-arnd@kernel.org Fixes: 503efe850c74 ("delayacct: add timestamp of delay max") Fixes: f06e31eef4c1 ("delayacct: fix uapi timespec64 definition") Signed-off-by: Arnd Bergmann Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202602091611.lxgINqXp-lkp@intel.com/ Signed-off-by: Andrew Morton

delayacct: add timestamp of delay max

2026-02-01T00:16:06+00:00

Problem ======= Commit 658eb5ab916d ("delayacct: add delay max to record delay peak") introduced the delay max for getdelays, which records abnormal latency peaks and helps us understand the magnitude of such delays. However, the peak latency value alone is insufficient for effective root cause analysis. Without the precise timestamp of when the peak occurred, we still lack the critical context needed to correlate it with other system events. Solution ======== To address this, we need to additionally record a precise timestamp when the maximum latency occurs. By correlating this timestamp with system logs and monitoring metrics, we can identify processes with abnormal resource usage at the same moment, which can help us to pinpoint root causes. Use Case ======== bash-4.4# ./getdelays -d -t 227 print delayacct stats ON TGID 227 CPU count real total virtual total delay total delay average delay max delay min delay max timestamp 46 188000000 192348334 4098012 0.089ms 0.429260ms 0.051205ms 2026-01-15T15:06:58 IO count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A SWAP count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A RECLAIM count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A THRAS HING count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A COMPACT count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A WPCOPY count delay total delay average delay max delay min delay max timestamp 182 19413338 0.107ms 0.547353ms 0.022462ms 2026-01-15T15:05:24 IRQ count delay total delay average delay max delay min delay max timestamp 0 0 0.000ms 0.000000ms 0.000000ms N/A Link: https://lkml.kernel.org/r/20260119100241520gWubW8-5QfhSf9gjqcc_E@zte.com.cn Signed-off-by: Wang Yaxin Cc: Fan Yu Cc: Jonathan Corbet Cc: xu xin Cc: Yang Yang Signed-off-by: Andrew Morton

tools/delaytop: improve error handling for missing PSI support

2025-09-14T00:32:56+00:00

Enhanced display logic to conditionally show PSI information only when successfully read, with helpful guidance for users to enable PSI support (psi=1 cmdline parameter). Link: https://lkml.kernel.org/r/20250907001417537vSx6nUsb3ILqI0iQ-WnGp@zte.com.cn Signed-off-by: Fan Yu Reviewed-by: xu xin Signed-off-by: Andrew Morton

tools/delaytop: add interactive mode with keyboard controls

2025-09-14T00:32:56+00:00

The original delaytop only supported static output with limited interaction. Users had to restart the tool with different command-line options to change sorting or display modes, which disrupted continuous monitoring and reduced productivity during performance investigations. Adds real-time interactive controls through keyboard input: 1) Add interactive menu system with visual prompts 2) Support dynamic sorting changes without restarting 3) Enable toggle of memory verbose mode with 'M' key The interactive mode transforms delaytop from a static monitoring tool into a dynamic investigation platform, allowing users to adapt the view in real-time based on observed performance patterns. Link: https://lkml.kernel.org/r/20250907001338580EURha20BxWFmBSrUpS8D1@zte.com.cn Signed-off-by: Fan Yu Reviewed-by: xu xin Signed-off-by: Andrew Morton

tools/delaytop: add memory verbose mode support

2025-09-14T00:32:55+00:00

The original delaytop tool always displayed detailed memory subsystem breakdown, which could be overwhelming for users who only need high-level overview. Add flexible display control allowing users to choose their preferred information granularity. The new flexibility provides: 1) For quick monitoring: use normal mode to reduce visual clutter 2) For deep analysis: use verbose mode to see all memory subsystem details Link: https://lkml.kernel.org/r/202509070012527934u0ySb3teQ4gOYKnocyNO@zte.com.cn Signed-off-by: Fan Yu Reviewed-by: xu xin Signed-off-by: Andrew Morton