From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, bpf <bpf@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas@fjasle.eu>,
Zheng Yejian <zhengyejian1@huawei.com>,
Martin Kelly <martin.kelly@crowdstrike.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: [PATCH v5 6/6] ftrace: Have ftrace pages output reflect freed pages
Date: Tue, 18 Feb 2025 14:59:24 -0500 [thread overview]
Message-ID: <20250218200023.221100846@goodmis.org> (raw)
In-Reply-To: 20250218195918.255228630@goodmis.org
From: Steven Rostedt <rostedt@goodmis.org>
The amount of memory that ftrace uses to save the descriptors to manage
the functions it can trace is shown at output. But if there are a lot of
functions that are skipped because they were weak or the architecture
added holes into the tables, then the extra pages that were allocated are
freed. But these freed pages are not reflected in the numbers shown, and
they can even be inconsistent with what is reported:
ftrace: allocating 57482 entries in 225 pages
ftrace: allocated 224 pages with 3 groups
The above shows the number of original entries that are in the mcount_loc
section and the pages needed to save them (225), but the second output
reflects the number of pages that were actually used. The two should be
consistent as:
ftrace: allocating 56739 entries in 224 pages
ftrace: allocated 224 pages with 3 groups
The above also shows the accurate number of entires that were actually
stored and does not include the entries that were removed.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/ftrace.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index e657013424aa..27c8def2139d 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -7006,6 +7006,7 @@ static int ftrace_process_locs(struct module *mod,
unsigned long addr;
unsigned long kaslr;
unsigned long flags = 0; /* Shut up gcc */
+ unsigned long pages;
int ret = -ENOMEM;
count = end - start;
@@ -7013,6 +7014,8 @@ static int ftrace_process_locs(struct module *mod,
if (!count)
return 0;
+ pages = DIV_ROUND_UP(count, ENTRIES_PER_PAGE);
+
/*
* Sorting mcount in vmlinux at build time depend on
* CONFIG_BUILDTIME_MCOUNT_SORT, while mcount loc in
@@ -7124,6 +7127,8 @@ static int ftrace_process_locs(struct module *mod,
for (pg = pg_unuse; pg; pg = pg->next)
remaining += 1 << pg->order;
+ pages -= remaining;
+
skip = DIV_ROUND_UP(skip, ENTRIES_PER_PAGE);
/*
@@ -7137,6 +7142,13 @@ static int ftrace_process_locs(struct module *mod,
synchronize_rcu();
ftrace_free_pages(pg_unuse);
}
+
+ if (!mod) {
+ count -= skipped;
+ pr_info("ftrace: allocating %ld entries in %ld pages\n",
+ count, pages);
+ }
+
return ret;
}
@@ -7782,9 +7794,6 @@ void __init ftrace_init(void)
goto failed;
}
- pr_info("ftrace: allocating %ld entries in %ld pages\n",
- count, DIV_ROUND_UP(count, ENTRIES_PER_PAGE));
-
ret = ftrace_process_locs(NULL,
__start_mcount_loc,
__stop_mcount_loc);
--
2.47.2
prev parent reply other threads:[~2025-02-18 20:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 19:59 [PATCH v5 0/6] scripts/sorttable: ftrace: Remove place holders for weak functions in available_filter_functions Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 1/6] arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64 Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 2/6] scripts/sorttable: Have mcount rela sort use direct values Steven Rostedt
2025-02-24 21:10 ` Arnd Bergmann
2025-02-24 22:21 ` Steven Rostedt
2025-02-25 2:11 ` Steven Rostedt
2025-02-25 8:45 ` Arnd Bergmann
2025-02-25 15:45 ` Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 3/6] scripts/sorttable: Always use an array for the mcount_loc sorting Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 4/6] scripts/sorttable: Zero out weak functions in mcount_loc table Steven Rostedt
2025-02-24 20:06 ` Mark Brown
2025-02-24 21:35 ` Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 5/6] ftrace: Update the mcount_loc check of skipped entries Steven Rostedt
2025-02-18 19:59 ` Steven Rostedt [this message]
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=20250218200023.221100846@goodmis.org \
--to=rostedt@goodmis.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.kelly@crowdstrike.com \
--cc=masahiroy@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=zhengyejian1@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).