[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YrVk4ElATQx4lcW0@hirez.programming.kicks-ass.net>
Date: Fri, 24 Jun 2022 09:16:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Josh Poimboeuf <jpoimboe@...hat.com>,
christophe.leroy@...roup.eu, naveen.n.rao@...ux.vnet.ibm.com,
mbenes@...e.cz
Subject: Re: [RFC][PATCH] ftrace,objtool: PC32 based __mcount_loc
On Wed, Jun 22, 2022 at 10:50:18AM -0400, Steven Rostedt wrote:
> On Fri, 17 Jun 2022 13:24:53 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:
>
> > Hi,
> >
> > I recently noticed that __mcount_loc is 64bit wide, containing absolute
> > addresses. Since __mcount_loc is a permanent section (not one we drop
> > after boot), this bloats the kernel memory usage for no real purpose.
>
> Wait, it's not dropped? Nothing uses it after it is read. It should be
> dropped when init data is dropped.
>
> From include/asm-generic/vmlinux.lds.h
>
> /* init and exit section handling */
> #define INIT_DATA \
> KEEP(*(SORT(___kentry+*))) \
> *(.init.data init.data.*) \
> MEM_DISCARD(init.data*) \
> KERNEL_CTORS() \
> MCOUNT_REC() \ <<----
> *(.init.rodata .init.rodata.*) \
> FTRACE_EVENTS() \
> TRACE_SYSCALLS() \
> KPROBE_BLACKLIST() \
> ERROR_INJECT_WHITELIST() \
> MEM_DISCARD(init.rodata) \
>
>
> So it should be dropped after boot.
Urgh, clearly I got lost somewhere along the line. In that case it
doesn't matter nearly as much.
Powered by blists - more mailing lists