From: Jiri Olsa <olsajiri@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Naveen N Rao <naveen@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jason Baron <jbaron@akamai.com>,
Alice Ryhl <aliceryhl@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ard Biesheuvel <ardb@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Alan Maguire <almagui@kernel.org>,
x86@kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH 01/13] static_call: Index code text reservation lookups
Date: Thu, 12 Nov 2026 19:33:03 +0100 [thread overview]
Message-ID: <avYGX1UpGlvbvHO5@krava> (raw)
In-Reply-To: <20261112101108.GE2669272@noisy.programming.kicks-ass.net>
On Thu, Nov 12, 2026 at 11:11:08AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 12, 2026 at 10:07:34AM +0100, Peter Zijlstra wrote:
> > Looking at this in a little more detail; I'm confused.
> >
> > You're literally adding an index, so that you can find the
> > static_call_size, while all you really need is static_call_addr().
>
> /size/site/ obviously :-)
>
> > That is, you could have just created an array of relocated site->addr
> > and sorted that, that would safe you a ton of indirection all around.
> >
> > That is:
> >
> > index->entries[i] = (long)static_call_addr(start + i) - (long)&index->entries[i];
>
> Should be:
>
> index->entries[i] = (long)static_call_addr(start + i) - (long)index->entries;
>
> They have to all be relative to one location in order for sorting to
> make sense.
>
> > That will make your lookup take at least half the amount of loads.
hum, but we still need the site’s init flag for static_call_is_init
I could store site pointer directly instead of the index and see how
much faster it is
> >
> >
> > Also, you really should support modules, there is no point being fast
> > until you load a module.
I had that, but decided to remove it because my follow up changes
did not support modules as well.. I will include it
jirka
next prev parent reply other threads:[~2026-11-12 18:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 19:49 [PATCH 00/13] kprobes: Reduce registration and optimization lookup costs Jiri Olsa
2026-11-09 19:49 ` [PATCH 01/13] static_call: Index code text reservation lookups Jiri Olsa
2026-11-12 8:27 ` Peter Zijlstra
2026-11-12 18:33 ` Jiri Olsa
2026-11-12 8:34 ` Peter Zijlstra
2026-11-12 18:33 ` Jiri Olsa
2026-11-12 9:07 ` Peter Zijlstra
2026-11-12 10:11 ` Peter Zijlstra
2026-11-12 18:33 ` Jiri Olsa [this message]
2026-11-09 19:49 ` [PATCH 02/13] jump_label: Index " Jiri Olsa
2026-11-12 8:33 ` Peter Zijlstra
2026-11-12 18:33 ` Jiri Olsa
2026-11-09 19:49 ` [PATCH 03/13] jump_label/x86: Avoid decoding instructions for jump entry size Jiri Olsa
2026-11-12 8:39 ` Peter Zijlstra
2026-11-12 18:33 ` Jiri Olsa
2026-11-09 19:55 ` [PATCH 04/13] kprobes: Maintain an rbtree of registered probes Jiri Olsa
2026-11-10 8:12 ` Masami Hiramatsu (Google)
2026-11-10 10:37 ` Jiri Olsa
2026-11-10 15:38 ` Masami Hiramatsu (Google)
2026-11-11 10:49 ` Jiri Olsa
2026-11-10 23:45 ` sashiko-bot
2026-11-12 8:50 ` Peter Zijlstra
2026-11-09 19:56 ` [PATCH 05/13] kprobes: Add an iterator for address ranges Jiri Olsa
2026-11-09 19:56 ` [PATCH 06/13] kprobes: Add an address iterator for probe lookup Jiri Olsa
2026-11-09 19:56 ` [PATCH 07/13] kprobes: Use kprobe iterator in get_optimized_kprobe Jiri Olsa
2026-11-09 19:57 ` [PATCH 08/13] x86/kprobes: Use kprobe iterator in __recover_optprobed_insn Jiri Olsa
2026-11-09 19:57 ` [PATCH 09/13] x86/kprobes: Use kprobe iterator in arch_check_optimized_kprobe Jiri Olsa
2026-11-11 0:17 ` sashiko-bot
2026-11-09 19:57 ` [PATCH 10/13] x86/kprobes: Use kprobe address iterator in can_optimize Jiri Olsa
2026-11-09 19:57 ` [PATCH 11/13] x86/kprobes: Use kprobe address iterator in can_probe Jiri Olsa
2026-11-09 19:58 ` [PATCH 12/13] x86/kprobes: Use kprobe address iterator in in copy_optimized_instructions Jiri Olsa
2026-11-09 19:58 ` [PATCH 13/13] samples/kprobes: Add batch probe example Jiri Olsa
2026-11-11 0:49 ` sashiko-bot
2026-11-11 2:20 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avYGX1UpGlvbvHO5@krava \
--to=olsajiri@gmail.com \
--cc=aliceryhl@google.com \
--cc=almagui@kernel.org \
--cc=ardb@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=jbaron@akamai.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=naveen@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.