BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <olsajiri@gmail.com>
Cc: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>,
	bpf@vger.kernel.org,  ast@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, kafai@meta.com,  kernel-team@meta.com,
	Mykyta Yatsenko <yatsenko@meta.com>
Subject: Re: [PATCH bpf-next] selftests/bpf: increase verifier log limit in veristat
Date: Mon, 21 Oct 2024 13:44:23 -0700	[thread overview]
Message-ID: <167627ec65ea21df19a6acefe186d591aaeef978.camel@gmail.com> (raw)
In-Reply-To: <CAEf4BzZ6b7drmHJN=Sf8Mjq6VB1Drg5g0LyeyN4URCRS63qTzA@mail.gmail.com>

On Mon, 2024-10-21 at 13:14 -0700, Andrii Nakryiko wrote:
> On Mon, Oct 21, 2024 at 9:44 AM Jiri Olsa <olsajiri@gmail.com> wrote:

[...]

> > IIUC this would try to use 1GB by default? seems to agresive.. could we perhaps
> > do that gradually and double the size on each failed load attempt?
> 
> The idea is that verifier will only page in as many pages as there is
> an actual log content (which normally would be much smaller than a
> full 1GB). Doing gradual size increase is actually pretty annoying in
> terms of how the code and logic is structured. So I think this
> approach is fine, overall.

As far as I understand, this feature is most useful for programs that
are close to 1M instructions limit. Such programs easily produce huge
logs. E.g. selftest pyperf600.bpf.o takes 627,288 instructions to
verify and generates 281MB of log. I agree with Andrii, that
allocating 1G for this purpose seems reasonable.

[...]


  parent reply	other threads:[~2024-10-21 20:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21 14:16 [PATCH bpf-next] selftests/bpf: increase verifier log limit in veristat Mykyta Yatsenko
2024-10-21 16:44 ` Jiri Olsa
2024-10-21 20:14   ` Andrii Nakryiko
2024-10-21 20:38     ` Mykyta Yatsenko
2024-10-21 20:44     ` Eduard Zingerman [this message]
2024-10-21 20:34   ` Mykyta Yatsenko

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=167627ec65ea21df19a6acefe186d591aaeef978.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@meta.com \
    --cc=kernel-team@meta.com \
    --cc=mykyta.yatsenko5@gmail.com \
    --cc=olsajiri@gmail.com \
    --cc=yatsenko@meta.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