From: Mark Rutland <mark.rutland@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Josh Poimboeuf <jpoimboe@redhat.com>,
christophe.leroy@csgroup.eu, naveen.n.rao@linux.vnet.ibm.com,
mbenes@suse.cz, Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [RFC][PATCH] ftrace,objtool: PC32 based __mcount_loc
Date: Thu, 23 Jun 2022 15:21:30 +0100 [thread overview]
Message-ID: <YrR26pFadVbt5RSh@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <20220622105436.775ccf7f@rorschach.local.home>
On Wed, Jun 22, 2022 at 10:54:36AM -0400, Steven Rostedt wrote:
> On Fri, 17 Jun 2022 12:40:00 +0100
> Mark Rutland <mark.rutland@arm.com> wrote:
>
> > We have a similar issue on arm64, which is exacerbated by needing ABS64
> > relocations (24 bytes per entry!) adding significant bloat when FTRACE is
> > enabled.
>
> I have patches that bring down the size quite a bit. The mcount loc is
> read into the dyn_rec, which has two longs (the second long is the
> flags that only use 32 bits, but is a long to make it aligned, as a 64
> bit word followed by a 32bit word just added 32 bits of padding to make
> it an array).
>
> The patches make it into two ints (which bring down the size for 64 bit
> machines). The lists are broken up into blocks, and what I do is put
> the top 32 bits of a word into the top of the block, and make sure that
> they are the same among all the entries in the block.
>
> I guess its time to bring this back alive.
I don't think that helps? I'm on about the size of the kernel "Image" file, not
the runtime memory footprint.
... unless you mean doing that at compiler time?
Mark.
next prev parent reply other threads:[~2022-06-23 14:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 11:24 Peter Zijlstra
2022-06-17 11:40 ` Mark Rutland
2022-06-21 16:27 ` Ard Biesheuvel
2022-06-23 14:19 ` Mark Rutland
2022-06-22 14:54 ` Steven Rostedt
2022-06-23 14:21 ` Mark Rutland [this message]
2022-06-24 0:01 ` Steven Rostedt
2022-06-17 11:44 ` Christophe Leroy
2022-06-17 12:06 ` Peter Zijlstra
2022-06-17 20:11 ` Josh Poimboeuf
2022-06-20 7:35 ` Peter Zijlstra
2022-06-20 7:42 ` Christophe Leroy
2022-06-22 14:50 ` Steven Rostedt
2022-06-24 7:16 ` Peter Zijlstra
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=YrR26pFadVbt5RSh@FVFF77S0Q05N.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=nathan@kernel.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®