[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <edb15f83-ddf9-ae48-6d1e-6ef7802e6f50@linux.alibaba.com>
Date: Tue, 16 Nov 2021 20:42:28 +0800
From: Yinan Liu <yinan@...ux.alibaba.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: rostedt@...dmis.org, mark-pk.tsai@...iatek.com, mingo@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] scripts: ftrace - move the sort-processing in
ftrace_init to compile time
在 2021/11/16 下午4:07, Peter Zijlstra 写道:
> /me hands a bucket of {} your way.
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6406,8 +6406,10 @@ static int ftrace_process_locs(struct module *mod,
if (!count)
return 0;
- sort(start, count, sizeof(*start),
- ftrace_cmp_ips, NULL);
+ if (mod) {
+ sort(start, count, sizeof(*start),
+ ftrace_cmp_ips, NULL);
+ }
hi,peter
you mean like this? I hope I'm not mistaken.
> Also, can't sorttable be ran on modules ?
The .ko file will be relocated after insmod or modprobe.
And the mcount redirection in .ko is based on ".text",
".init.text", ".ref.text", ".sched.text", ".spinlock.text",
".irqentry .text", ".softirqentry.text", ".kprobes.text",
".cpuidle.text", ".text.unlikely". These sections‘ loading
position are not in definite order.
So sorting this part at compile time doesn't make much sense.
Best regards!
--Yinan liu
Powered by blists - more mailing lists