All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, martin.lau@linux.dev, kernel-team@fb.com,
	yonghong.song@linux.dev
Subject: Re: [PATCH RFC bpf-next v3 4/6] bpf: report hot simulated callchains when 1M instructions limit is met
Date: Sat, 30 May 2026 11:34:36 +0200	[thread overview]
Message-ID: <ahqvLKBAA88GWHgP@krava> (raw)
In-Reply-To: <17304ac9808245282aa2f03f26665cccd6fc185f.camel@gmail.com>

On Fri, May 29, 2026 at 11:44:39AM -0700, Eduard Zingerman wrote:
> On Fri, 2026-05-29 at 12:23 +0200, Jiri Olsa wrote:
> > On Wed, May 27, 2026 at 12:29:52AM -0700, Eduard Zingerman wrote:
> > 
> > SNIP
> > 
> > > +
> > >  static int do_check_insn(struct bpf_verifier_env *env, bool *do_print_state)
> > >  {
> > >  	int err;
> > > @@ -17381,6 +17527,7 @@ static int do_check(struct bpf_verifier_env *env)
> > >  		insn_aux = &env->insn_aux_data[env->insn_idx];
> > >  
> > >  		if (++env->insn_processed > BPF_COMPLEXITY_LIMIT_INSNS) {
> > > +			print_hotspots(env);
> > 
> > hi,
> > this is really cool feature, I've already used it to fix issues :)
> 
> Hi Jiri, thank you for the feedback!
> Anything you find lacking?

so in my case the first 2 stacktraces identified data copy deep in
the code, which was wrongly done with standard loop instead of bpf_iter,
so it led me directly to the problem

In another run I got the 'Most varying ...' output and it wasn't
that obvious for me how helpful that could be, but I did not check
on that in detail yet

> 
> After discussion with Alexei (who is somewhat skeptical of the whole idea),
> I plan to add:
> - samples for values residing in the diverging registers
> - walk back from iter_next call using jump history and
>   print 5-10 instructions modifying the register in question
>   (in a manner similar to backtracking done for mark chain precision).
> 
> > Would it be possible to make this configurable? like to be able
> > to get this output for program that passed and display more than
> > 3 hottest callchains?
> 
> For sure, there are several options for a way to toggle this print out:
> - unconditionally make it a part of v1 log;
> - add it as a bit in bpf_attr->log_level.
> 
> I'd say that v1 log is a better option here.

sounds good, I think it's negligible compared to the rest of the log

> 
> As for number of callchains printed, I'd like to avoid tweaking

I guess it's better to have it hardcoded, no need to configure that

> bpf_attr. So this leaves several options:
> - make it top 5-7-10, just hardcode a bigger number.
> - add a threshold value specifying how many times a callchain should
>   be visited to get printed. E.g. only print callchains visited more
>   than 1000 times, if such don't exist then put threshold to 100,
>   if such don't exist, print top 3.

+1 to just print top X stacks

thanks,
jirka

  reply	other threads:[~2026-05-30  9:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  7:29 [PATCH RFC bpf-next v3 0/6] bpf: better error reporting when verifier hits 1M instructions limit Eduard Zingerman
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 1/6] bpf: move live registers and scc printout to a standalone function Eduard Zingerman
2026-06-01  5:50   ` Emil Tsalapatis
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 2/6] bpf: compute loops hierarchy Eduard Zingerman
2026-06-01 19:12   ` Emil Tsalapatis
2026-06-01 19:22     ` Eduard Zingerman
2026-06-01 19:29       ` Emil Tsalapatis
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 3/6] selftests/bpf: test cases for loop hierarchy computation Eduard Zingerman
2026-05-27  8:50   ` sashiko-bot
2026-06-01 19:37   ` Emil Tsalapatis
2026-06-01 19:44     ` Eduard Zingerman
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 4/6] bpf: report hot simulated callchains when 1M instructions limit is met Eduard Zingerman
2026-05-29 10:23   ` Jiri Olsa
2026-05-29 18:44     ` Eduard Zingerman
2026-05-30  9:34       ` Jiri Olsa [this message]
2026-06-01 19:50   ` Emil Tsalapatis
2026-06-01 19:55     ` Eduard Zingerman
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 5/6] bpf: report register diff summary for hot callchains Eduard Zingerman
2026-06-01 21:29   ` Emil Tsalapatis
2026-06-01 21:38     ` Eduard Zingerman
2026-05-27  7:29 ` [PATCH RFC bpf-next v3 6/6] selftests/bpf: test budget exhaustion profiling report Eduard Zingerman
2026-06-01 19:55   ` Emil Tsalapatis

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=ahqvLKBAA88GWHgP@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@linux.dev \
    --cc=yonghong.song@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.