linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>, bpf <bpf@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Kajol Jain <kjain@linux.ibm.com>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v5 bpf-next 2/3] bpf: introduce helper bpf_get_branch_snapshot
Date: Fri, 3 Sep 2021 10:10:16 -0700	[thread overview]
Message-ID: <CAEf4BzZ0eq1iFh1oVwTZ7+bQkb=pJShgDWzUSAp41sk30iQunQ@mail.gmail.com> (raw)
In-Reply-To: <YTHhOy1gqr44C1bI@hirez.programming.kicks-ass.net>

On Fri, Sep 3, 2021 at 1:49 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Sep 02, 2021 at 09:57:05AM -0700, Song Liu wrote:
> > +BPF_CALL_3(bpf_get_branch_snapshot, void *, buf, u32, size, u64, flags)
> > +{
> > +     static const u32 br_entry_size = sizeof(struct perf_branch_entry);
> > +     u32 entry_cnt = size / br_entry_size;
> > +
> > +     if (unlikely(flags))
> > +             return -EINVAL;
> > +
> > +     if (!buf || (size % br_entry_size != 0))

I think buf can't be NULL, this should be enforced already by verifier
due to ARG_PTR_TO_UNINIT_MEM, so we can drop that.

> > +             return -EINVAL;
> > +
> > +     entry_cnt = static_call(perf_snapshot_branch_stack)(buf, entry_cnt);
>
> That's at least 2, possibly 3 branches just from the sanity checks, plus
> at least one from starting the BPF prog and one from calling this
> function, gets you at ~5 branch entries gone before you even do the
> snapshot thing.
>
> Less if you're in branch-stack mode.
>
> Can't the validator help with getting rid of the some of that?
>

Good points. I think we can drop !buf check completely. The flags and
size checks can be moved after perf_snapshot_branch_stack call. In
common cases those checks should always pass, but even if they don't
we'll just capture the LBR anyways, but will return an error later,
which seems totally acceptable.

As Alexei mentioned, there is a whole non-inlined migrate_disable()
call before this, which we should inline as well. It's good for
performance, not just LBR.

> I suppose you have to have this helper function because the JIT cannot
> emit static_call()... although in this case one could cheat and simply
> emit a call to static_call_query() and not bother with dynamic updates
> (because there aren't any).

If that's safe, let's do it.

  parent reply	other threads:[~2021-09-03 17:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 16:57 [PATCH v5 bpf-next 0/3] bpf: introduce bpf_get_branch_snapshot Song Liu
2021-09-02 16:57 ` [PATCH v5 bpf-next 1/3] perf: enable branch record for software events Song Liu
2021-09-02 20:49   ` John Fastabend
2021-09-03  8:02   ` Peter Zijlstra
2021-09-03 16:50     ` Song Liu
2021-09-07 18:59       ` Song Liu
2021-09-07 20:50         ` Andrii Nakryiko
2021-09-03  8:27   ` Peter Zijlstra
2021-09-03 16:45     ` Song Liu
2021-09-04 10:18       ` Peter Zijlstra
2021-09-02 16:57 ` [PATCH v5 bpf-next 2/3] bpf: introduce helper bpf_get_branch_snapshot Song Liu
2021-09-02 20:56   ` John Fastabend
2021-09-02 22:04     ` Song Liu
2021-09-02 22:53   ` Andrii Nakryiko
2021-09-02 23:03     ` Song Liu
2021-09-02 23:05       ` Andrii Nakryiko
2021-09-03  1:03   ` Alexei Starovoitov
2021-09-03  8:28   ` Peter Zijlstra
2021-09-03 16:58     ` Song Liu
2021-09-03  8:47   ` Peter Zijlstra
2021-09-03 17:06     ` Song Liu
2021-09-03 17:10     ` Andrii Nakryiko [this message]
2021-09-04 10:24       ` Peter Zijlstra
2021-09-04 10:55         ` Peter Zijlstra
2021-09-02 16:57 ` [PATCH v5 bpf-next 3/3] selftests/bpf: add test for bpf_get_branch_snapshot Song Liu
2021-09-02 21:05   ` John Fastabend
2021-09-02 22:54 ` [PATCH v5 bpf-next 0/3] bpf: introduce bpf_get_branch_snapshot Andrii Nakryiko

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='CAEf4BzZ0eq1iFh1oVwTZ7+bQkb=pJShgDWzUSAp41sk30iQunQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=acme@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@fb.com \
    --cc=kjain@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --subject='Re: [PATCH v5 bpf-next 2/3] bpf: introduce helper bpf_get_branch_snapshot' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).