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

[Dmitry Dolgov]

> On Wed, Jul 20, 2022 at 04:07:36PM +0200, Peter Zijlstra wrote:
> > > > 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?

Do you mean there is an existing sysctl option for maxactive, or propose
to introduce one? A global option indeed could be fine for my use case I
guess, although there will be a bit of awkward asymmetry -- one can
specify maxactive via text-based API, but not via perf API.

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

Yes, you're right, I was referring to UPROBE_REF_CTR. Makes sense to me,
will change the location.