Re: [PATCH 04/13] kprobes: Maintain an rbtree of registered probes

[Jiri Olsa]

On Wed, Nov 11, 2026 at 12:38:03AM +0900, Masami Hiramatsu (Google) wrote:
> On Tue, 10 Nov 2026 11:37:38 +0100, Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> > On Tue, Nov 10, 2026 at 08:12:19AM +0000, Masami Hiramatsu (Google) wrote:
> > > On Mon,  9 Nov 2026 20:55:17 +0100, Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> > > > Add an address-ordered rbtree for registered probes. Keep it synchronized
> > > > with the hash table when probes are added, removed, or replaced by
> > > > aggregator probes.
> > > 
> > > Could you tell me why don't you use hlist (get_kprobe) instead?
> > > I would NOT like 2 different lists which is basically doing the
> > > same thing.
> > 
> > The speedup comes from finding the first relevant kprobe, then iterating
> > over the remaining probes in address order. The hash table supports
> > exact-address lookups, but it doesn’t provide that ordering.
> > 
> > I agree that maintaining both indexes is less convenient. What do you think
> > about centralizing their updates as in the change below? untested
> 
> If you can replace the hash table with other faster design, it is OK to me.
> But I would like to avoid this simple-adding another lookup table for the
> rare usage case (because of the maintenance cost, and duplicating a list
> makes it difficult to handle cases where discrepancies arise between the
> two lists.)
> 
> Can you change the size of the hashtable and measure how the performance
> is changed? I need more options.

yep, I'll check on that

jirka