Re: [PATCH v4 1/1] perf/kprobe: maxactive for fd-based kprobe

[Peter Zijlstra]

On Fri, Jul 15, 2022 at 11:52:36AM +0200, Dmitry Dolgov wrote:
> > 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@xxxxxx>
> > >
> > > 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.

But why would we need per-fd configurability? Isn't a global sysctrl
good enough?

> > 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?

I think the precedent you're referring to is UPROBE_REF_CTR, which is a
full 32bit. That lives in the upper half of the word because bit0 is
already taken and using the upper half makes the thing naturally
aligned.

If we only need 4 bits it's must simpler to simply stick it at the
bottom or so.

> 
> > > 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.

Masami; how hard would it be to do this? Creating an ABI for something
that's already planned to be removed seems unfortunate, it would be best
to see if we can find someone to accelerate this work.