BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Mahe Tardy <mahe.tardy@gmail.com>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend	 <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Paul Chaignon	 <paul.chaignon@gmail.com>,
	Shung-Hsi Yu <shung-hsi.yu@suse.com>
Subject: Re: [PATCH bpf-next] verifier: add prune points to live registers print
Date: Tue, 30 Dec 2025 21:47:53 -0800	[thread overview]
Message-ID: <48548c462733962bf415a568f52bb312af0ee1b2.camel@gmail.com> (raw)
In-Reply-To: <CAADnVQLi_qYzqprvTNT+fHp2WgC5uPAHBKAN6Rr6sAhLvRqjoA@mail.gmail.com>

On Tue, 2025-12-30 at 17:11 -0800, Alexei Starovoitov wrote:
> On Tue, Dec 30, 2025 at 10:44 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > 
> > > 
> > > that will make post processing easier, but print on every miss
> > > will greatly increase log_level=2 size, right ?
> > 
> > Here are some stats for pyperf180:
> > 
> > > Experiment                                  | Log   | Log  |
> > > Kind                                        | Lines | Size |
> > > ---------------------------------------------+-------+------|
> > > Print cache hits, misses and diffing values | 626K  | 88M  |
> > > Print cache misses and diffing values       | 618K  | 88M  |
> > > Print cache misses                          | 618K  | 87M  |
> > > Default level 2 log                         | 577K  | 85M  |
> 
> hmm. That's not that much.
> Then I don't understand why you said:
> "slows down log level 2 output significantly (~5 times)"
> 
> If the total output is roughly the same, how come it's 5 times slower??

That's an interesting question.
Double checked the log for the failing program I was debugging
(internal, hits 1M limit): 6M lines total, 1.4M lines are "cache ...",
so 20% instead of 8% for pyperf180.
Still does not explain the performance difference.
I'll check what happens using profiler.

      reply	other threads:[~2025-12-31  5:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-22 18:58 [PATCH bpf-next] verifier: add prune points to live registers print Mahe Tardy
2025-12-22 20:50 ` Yonghong Song
2025-12-23  6:32 ` Alexei Starovoitov
2025-12-23 10:12   ` Mahe Tardy
2025-12-29 18:48     ` Eduard Zingerman
2025-12-30  0:42       ` Alexei Starovoitov
2025-12-30  1:13         ` Eduard Zingerman
2025-12-30 18:06           ` Alexei Starovoitov
2025-12-30 18:44             ` Eduard Zingerman
2025-12-31  1:11               ` Alexei Starovoitov
2025-12-31  5:47                 ` Eduard Zingerman [this message]

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=48548c462733962bf415a568f52bb312af0ee1b2.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=mahe.tardy@gmail.com \
    --cc=paul.chaignon@gmail.com \
    --cc=shung-hsi.yu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox