On Wed, Jan 11, 2023 at 04:41:21PM +0800, Leizhen (ThunderTown) wrote:

On 2023/1/9 23:11, Leizhen (ThunderTown) wrote:

quoted

On 2023/1/9 21:48, Jiri Olsa wrote:

quoted

On Mon, Jan 09, 2023 at 04:51:37PM +0800, Leizhen (ThunderTown) wrote:

quoted

On 2023/1/6 17:45, Jiri Olsa wrote:

quoted

On Thu, Jan 05, 2023 at 10:31:12PM +0100, Jiri Olsa wrote:

quoted

On Wed, Jan 04, 2023 at 05:25:08PM +0100, Petr Mladek wrote:

quoted

On Fri 2022-12-30 19:27:28, Zhen Lei wrote:

quoted

Function __module_address() can quickly return the pointer of the module
to which an address belongs. We do not need to traverse the symbols of all
modules to check whether each address in addrs[] is the start address of
the corresponding symbol, because register_fprobe_ips() will do this check
later.

hum, for some reason I can see only replies to this patch and
not the actual patch.. I'll dig it out of the lore I guess

quoted

quoted

Assuming that there are m modules, each module has n symbols on average,
and the number of addresses 'addrs_cnt' is abbreviated as K. Then the time
complexity of the original method is O(K * log(K)) + O(m * n * log(K)),
and the time complexity of current method is O(K * (log(m) + M)), M <= m.
(m * n * log(K)) / (K * m) ==> n / log2(K). Even if n is 10 and K is 128,
the ratio is still greater than 1. Therefore, the new method will
generally have better performance.

could you try to benchmark that? I tried something similar but was not
able to get better performance

hm looks like I tried the smilar thing (below) like you did,

Yes. I just found out you're working on this improvement, too.

quoted

but wasn't able to get better performace

Your implementation below is already the limit that can be optimized.
If the performance is not improved, it indicates that this place is
not the bottleneck.

quoted

I guess your goal is to get rid of the module arg in
module_kallsyms_on_each_symbol callback that we use?

It's not a bad thing to keep argument 'mod' for function
module_kallsyms_on_each_symbol(), but for kallsyms_on_each_symbol(),
it's completely redundant. Now these two functions often use the
same hook function. So I carefully analyzed get_modules_for_addrs(),
which is the only place that involves the use of parameter 'mod'.
Looks like there's a possibility of eliminating parameter 'mod'.

quoted

I'm ok with the change if the performace is not worse

OK, thanks.

quoted

jirka


---

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 5b9008bc597b..3280c22009f1 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c

@@ -2692,23 +2692,16 @@ struct module_addr_args {
 	int mods_cap;
 };
 
-static int module_callback(void *data, const char *name,
-			   struct module *mod, unsigned long addr)
+static int add_module(struct module_addr_args *args, struct module *mod)
 {
-	struct module_addr_args *args = data;
 	struct module **mods;
 
-	/* We iterate all modules symbols and for each we:
-	 * - search for it in provided addresses array
-	 * - if found we check if we already have the module pointer stored
-	 *   (we iterate modules sequentially, so we can check just the last
-	 *   module pointer)
+	/* We iterate sorted addresses and for each within module we:
+	 * - check if we already have the module pointer stored for it
+	 *   (we iterate sorted addresses sequentially, so we can check
+	 *   just the last module pointer)
 	 * - take module reference and store it
 	 */
-	if (!bsearch(&addr, args->addrs, args->addrs_cnt, sizeof(addr),
-		       bpf_kprobe_multi_addrs_cmp))
-		return 0;
-
 	if (args->mods && args->mods[args->mods_cnt - 1] == mod)
 		return 0;

There'll be problems Petr mentioned.

https://lkml.org/lkml/2023/1/5/191

ok, makes sense.. I guess we could just search args->mods in here?
are you going to send new version, or should I update my patch with that?

It's better for you to update! I'm not familiar with the bpf module.

Hi Jiri:
  Can you attach patch 1/3 when you send the new patch? There's a little
dependency. Petr has already replied OK to patch 1/3, see [1].
  Patch 3/3 is just a cleanup, I'll delay updating it after v6.3-rc1, it
also has a dependency on another patch [2].

ok, will do

jirka