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