[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YTHhOy1gqr44C1bI@hirez.programming.kicks-ass.net>
Date: Fri, 3 Sep 2021 10:47:55 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Song Liu <songliubraving@...com>
Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org, acme@...nel.org,
mingo@...hat.com, kjain@...ux.ibm.com, kernel-team@...com
Subject: Re: [PATCH v5 bpf-next 2/3] bpf: introduce helper
bpf_get_branch_snapshot
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))
> + 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?
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).
Powered by blists - more mailing lists