From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 2/3] perf sched latency: Auto-scale latency and runtime display units
Date: Sat, 25 Jul 2026 17:39:33 +0000 [thread overview]
Message-ID: <20260725173934.1D5241F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260725173341.679782-3-atomlin@atomlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The table column alignment in `perf sched latency` is broken by the new formatting widths, contradicting the commit message's claim of maintaining column alignment.
--
--- Patch [2]: [PATCH v2 2/3] perf sched latency: Auto-scale latency and runtime display units ---
commit bd1f9f65443ae53474112d9990f8290686a5aaa3
Author: Aaron Tomlin <atomlin@atomlin.com>
perf sched latency: Auto-scale latency and runtime display units
This commit introduces dynamic scaling for latency and runtime values in
'perf sched latency' output. It replaces hardcoded millisecond output with
auto-scaled units (ns, us, ms, s) and updates the table formatting to
improve readability.
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> index b3cf678573e0a..00ff5abb08b57 100644
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
[ ... ]
> @@ -1430,14 +1443,17 @@ static void output_lat_thread(struct perf_sched *sched, struct work_atoms *work_
> printf(" ");
>
> avg = work_list->total_lat / work_list->nb_atoms;
> + scnprintf_latency_unit(runtime_lat, sizeof(runtime_lat), work_list->total_runtime);
> + scnprintf_latency_unit(avg_lat, sizeof(avg_lat), avg);
> + scnprintf_latency_unit(max_lat, sizeof(max_lat), work_list->max_lat);
> timestamp__scnprintf_usec(work_list->max_lat_start, max_lat_start, sizeof(max_lat_start));
> timestamp__scnprintf_usec(work_list->max_lat_end, max_lat_end, sizeof(max_lat_end));
>
> - printf("|%11.3f ms |%9" PRIu64 " | avg:%8.3f ms | max:%8.3f ms | max start: %12s s | max end: %12s s\n",
> - (double)work_list->total_runtime / NSEC_PER_MSEC,
> - work_list->nb_atoms, (double)avg / NSEC_PER_MSEC,
> - (double)work_list->max_lat / NSEC_PER_MSEC,
> - max_lat_start, max_lat_end);
> + printf("|%13s |%9" PRIu64 " | avg:%10s | max:%10s | max start: %12s s | max end: %12s s\n",
> + runtime_lat,
> + work_list->nb_atoms, avg_lat, max_lat,
> + max_lat_start, max_lat_end);
> +
> }
[Severity: Low]
Does this format string break the column alignment?
The table header defines a width of 15 characters for the "Runtime" column
(| Runtime |), and 17 characters for the "Avg delay" and "Max delay"
columns. The new formats %13s and avg:%10s produce strings that are shorter
than these expected widths, which appears to cause the vertical bar separators
to misalign.
[ ... ]
> @@ -3612,7 +3629,7 @@ static int perf_sched__lat(struct perf_sched *sched)
> perf_sched__sort_lat(sched);
>
> printf("\n -------------------------------------------------------------------------------------------------------------------------------------------\n");
> - printf(" Task | Runtime ms | Count | Avg delay ms | Max delay ms | Max delay start | Max delay end |\n");
> + printf(" Task | Runtime | Count | Avg delay | Max delay | Max delay start | Max delay end |\n");
> printf(" -------------------------------------------------------------------------------------------------------------------------------------------\n");
[ ... ]
> @@ -3626,8 +3643,9 @@ static int perf_sched__lat(struct perf_sched *sched)
> }
>
> printf(" -----------------------------------------------------------------------------------------------------------------\n");
> - printf(" TOTAL: |%11.3f ms |%9" PRIu64 " |\n",
> - (double)sched->all_runtime / NSEC_PER_MSEC, sched->all_count);
> + scnprintf_latency_unit(total_runtime_str, sizeof(total_runtime_str), sched->all_runtime);
> + printf(" TOTAL: |%13s |%9" PRIu64 " |\n",
> + total_runtime_str, sched->all_count);
>
> printf(" ---------------------------------------------------\n");
[Severity: Low]
Does the use of %13s here also break the vertical alignment of the first
column for the TOTAL row summary?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260725173341.679782-1-atomlin@atomlin.com?part=2
next prev parent reply other threads:[~2026-07-25 17:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 17:33 [PATCH v2 0/3] perf sched latency: Refine outputs, unit scaling, and histogram support Aaron Tomlin
2026-07-25 17:33 ` [PATCH v2 1/3] perf sched: Suppress latency table output when trace samples are missing Aaron Tomlin
2026-07-25 17:33 ` [PATCH v2 2/3] perf sched latency: Auto-scale latency and runtime display units Aaron Tomlin
2026-07-25 17:39 ` sashiko-bot [this message]
2026-07-26 1:42 ` Aaron Tomlin
2026-07-25 17:33 ` [PATCH v2 3/3] perf sched latency: Add histogram and time interval options Aaron Tomlin
2026-07-25 17:44 ` sashiko-bot
2026-07-26 2:05 ` Aaron Tomlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260725173934.1D5241F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atomlin@atomlin.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.