All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	James Clark <james.clark@linaro.org>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH 3/5] perf report: Add --no-progress option
Date: Tue, 29 Sep 2026 16:48:12 -0700	[thread overview]
Message-ID: <arxOPEU1bCePHzVx@google.com> (raw)
In-Reply-To: <20260929212246.2532021-4-acme@kernel.org>

On Tue, Sep 29, 2026 at 11:22:44PM +0200, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> Add the counterpart of --progress: the TUI and GTK browsers present
> progress of their own and there is no way to turn it off, while the
> option just added allows asking for it when there is none.  Install the
> no-op ui_progress ops, the ones already used until a backend sets
> theirs, after setup_browser() installed them.  The phases are still
> counted, nothing is shown for them, and --no-progress takes precedence
> over --progress.

Hmm.. I mean --progress already gives --no-progress for free.  We just
need to handle that for TUI and GTK.

Thanks,
Namhyung

> 
> Suggested-by: Namhyung Kim <namhyung@kernel.org>
> Assisted-by: LLM
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
>  tools/perf/Documentation/perf-report.txt |  5 +++++
>  tools/perf/builtin-report.c              | 17 ++++++++++++++---
>  tools/perf/ui/progress.c                 |  6 ++++++
>  tools/perf/ui/progress.h                 |  2 ++
>  4 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
> index a7429a30ec28f903..bc0f2031b100f425 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -43,6 +43,11 @@ OPTIONS
>  	present progress information, or when --quiet is used, that asks
>  	for no messages at all.
>  
> +--no-progress::
> +	Do not show progress while processing the perf.data file.  It
> +	also turns off the progress the TUI and GTK browsers present,
> +	which is their own, and takes precedence over --progress.
> +
>  -n::
>  --show-nr-samples::
>  	Show the number of samples for each symbol
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 963808b561e547c3..8d23c077fab5f874 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -88,6 +88,7 @@ struct report {
>  #endif
>  	bool			use_stdio;
>  	bool			progress;
> +	bool			no_progress;
>  	bool			show_full_info;
>  	bool			show_threads;
>  	bool			inverted_callchain;
> @@ -1385,8 +1386,16 @@ int cmd_report(int argc, const char **argv)
>  		    "Use the stdio interface"),
>  	OPT_BOOLEAN(0, "weights", &symbol_conf.annotate_weight,
>  			"Show or hide weight columns in annotation. Default show if non-zero."),
> -	OPT_BOOLEAN(0, "progress", &report.progress,
> -		    "Show progress while processing the perf.data file"),
> +	/*
> +	 * Not auto negatable: parse-options turns --no-progress into the
> +	 * negation of this option before it ever reaches the --no-progress
> +	 * below, which is the one that also turns off the TUI and GTK progress.
> +	 */
> +	OPT_BOOLEAN_FLAG(0, "progress", &report.progress,
> +			 "Show progress while processing the perf.data file",
> +			 PARSE_OPT_NOAUTONEG),
> +	OPT_BOOLEAN(0, "no-progress", &report.no_progress,
> +		    "Do not show progress while processing the perf.data file"),
>  	OPT_BOOLEAN(0, "header", &report.header, "Show data header."),
>  	OPT_BOOLEAN(0, "header-only", &report.header_only,
>  		    "Show only data header."),
> @@ -1798,7 +1807,9 @@ int cmd_report(int argc, const char **argv)
>  	 * processed so far for each processing phase.  --quiet asks for no
>  	 * messages at all, so it leaves the phases uncounted.
>  	 */
> -	if (report.progress && !quiet && use_browser == 0)
> +	if (report.no_progress)
> +		ui_progress__noop_init();
> +	else if (report.progress && !quiet && use_browser == 0)
>  		stdio_progress__init();
>  
>  	if (report.data_type && use_browser == 1) {
> diff --git a/tools/perf/ui/progress.c b/tools/perf/ui/progress.c
> index 99d60223c74b2957..362680989ace606a 100644
> --- a/tools/perf/ui/progress.c
> +++ b/tools/perf/ui/progress.c
> @@ -13,6 +13,12 @@ static struct ui_progress_ops null_progress__ops =
>  
>  struct ui_progress_ops *ui_progress__ops = &null_progress__ops;
>  
> +/* Everything counts but nothing is shown, the way it starts out. */
> +void ui_progress__noop_init(void)
> +{
> +	ui_progress__ops = &null_progress__ops;
> +}
> +
>  void ui_progress__update(struct ui_progress *p, u64 adv)
>  {
>  	u64 last = p->curr;
> diff --git a/tools/perf/ui/progress.h b/tools/perf/ui/progress.h
> index 03f1a8bb260ba076..e8c4f9f768aaf12b 100644
> --- a/tools/perf/ui/progress.h
> +++ b/tools/perf/ui/progress.h
> @@ -25,6 +25,8 @@ void ui_progress__update(struct ui_progress *p, u64 adv);
>  
>  void stdio_progress__init(void);
>  
> +void ui_progress__noop_init(void);
> +
>  struct ui_progress_ops {
>  	void (*init)(struct ui_progress *p);
>  	void (*update)(struct ui_progress *p);
> -- 
> 2.55.0
> 

  parent reply	other threads:[~2026-09-29 23:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 21:22 [PATCH v5 0/5] perf tools: Add progress diagnostics and a false-sharing workload Arnaldo Carvalho de Melo
2026-09-29 21:22 ` [PATCH 1/5] perf config: Move perf_config__set_variable() to util/config.c Arnaldo Carvalho de Melo
2026-09-29 21:45   ` sashiko-bot
2026-09-29 21:22 ` [PATCH 2/5] perf report: Add --progress option Arnaldo Carvalho de Melo
2026-09-29 21:28   ` sashiko-bot
2026-09-29 21:22 ` [PATCH 3/5] perf report: Add --no-progress option Arnaldo Carvalho de Melo
2026-09-29 21:28   ` sashiko-bot
2026-09-29 23:48   ` Namhyung Kim [this message]
2026-09-29 21:22 ` [PATCH 4/5] perf scripts: Add perf-stuck, to tell where a running perf is stuck Arnaldo Carvalho de Melo
2026-09-29 21:29   ` sashiko-bot
2026-09-29 21:22 ` [PATCH 5/5] perf test: Add false_sharing workload exhibiting cross-CPU false sharing Arnaldo Carvalho de Melo
2026-09-29 21:28   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-09-29 20:15 [PATCH v4 0/5] perf tools: Add progress diagnostics and a false-sharing workload Arnaldo Carvalho de Melo
2026-09-29 20:15 ` [PATCH 3/5] perf report: Add --no-progress option Arnaldo Carvalho de Melo
2026-09-29 20:24   ` sashiko-bot

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=arxOPEU1bCePHzVx@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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.