[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220715095236.ywv37a556ktl5oif@ddolgov.remote.csb>
Date: Fri, 15 Jul 2022 11:52:36 +0200
From: Dmitry Dolgov <9erthalion6@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
songliubraving@...com, rostedt@...dmis.org, mingo@...hat.com,
mhiramat@...nel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH v4 1/1] perf/kprobe: maxactive for fd-based kprobe
> On Thu, Jul 14, 2022 at 09:57:48PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 14, 2022 at 09:34:03PM +0200, Dmitrii Dolgov wrote:
> > From: Song Liu <songliubraving@...com>
> >
> > Enable specifying maxactive for fd based kretprobe. This will be useful
> > for tracing tools like bcc and bpftrace (see for example discussion [1]).
> > Use highest 4 bit (bit 59-63) to allow specifying maxactive by log2.
>
> What's maxactive? This doesn't really tell me much.
Maxactive allows specifying how many instances of the specified function
can be probed simultaneously, it would indeed make sense to mention this
in the commit message.
> Why are the top 4 bits the best to use?
This format exists mostly on proposal rights. Per previous discussions,
4 bits seem to be enough to cover reasonable range of maxactive values.
Top bits seems like a natural place to me following perf_probe_config
enum, but I would love to hear if there are any alternative suggestions?
> > The original patch [2] seems to be fallen through the cracks and wasn't
> > applied. I've merely rebased the work done by Song Liu, verififed it
> > still works, and modified to allow specifying maxactive by log2 per
> > suggestion from the discussion thread.
>
> That just doesn't belong in a Changelog.
Agree.
> > Note that changes in rethook implementation may render maxactive
> > obsolete.
>
> Then why bother creating an ABI for it?
If I got Masami right, those potential changes mentioned above are only
on the planning stage. At the same time the issue is annoying enough to
try to solve it already now.
> > [1]: https://github.com/iovisor/bpftrace/issues/835
> > [2]: https://lore.kernel.org/all/20191007223111.1142454-1-songliubraving@fb.com/
> >
> > Signed-off-by: Song Liu <songliubraving@...com>
> > Signed-off-by: Dmitrii Dolgov <9erthalion6@...il.com>
> > Reviewed-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> > Acked-by: Steven Rostedt (Google) <rostedt@...dmis.org>
>
> Lots of question and not a single answer in sight...
I hope I was able to answer at least some of them, thanks for looking
into this!
Powered by blists - more mailing lists