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

[Masami Hiramatsu (Google)]

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.

Thanks,

> 
> jirka
> 
> 

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>