From: Nick Alcock <nick.alcock@oracle.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: thunder.leizhen@huawei.com, masahiroy@kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
arnd@arndb.de, akpm@linux-foundation.org, eugene.loh@oracle.com,
kris.van.hees@oracle.com, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules
Date: Mon, 14 Nov 2022 17:04:55 +0000 [thread overview]
Message-ID: <87mt8tv554.fsf@esperi.org.uk> (raw)
In-Reply-To: <Y3BhRvt53xO5A0iQ@bombadil.infradead.org> (Luis Chamberlain's message of "Sat, 12 Nov 2022 19:15:18 -0800")
On 13 Nov 2022, Luis Chamberlain outgrape:
> On Wed, Nov 09, 2022 at 01:41:28PM +0000, Nick Alcock wrote:
>> The mapping consists of three new symbols
>
> The entire commit log does not describe *why*.
... because it's in the other commit logs and the cover letter. I can
repeat the motivation in this log too if you like.
> Can I also trouble you to rebase on top of modules-next [0]
Sure!
> Does the kallsyms loop more than 3 times now with Zhen Lei's work and
> your new symbols on top on a allyesconfig build?
I don't understand the question, sorry. If this is about the number of
KALLSYMS invocations in the kernel build, that should be unchanged by
this patch. This was an explicit design goal because it's quite slow to
run kallsyms more times and I was already feeling guilty about having to
bring back the tristate recursion.
I haven't tried it with Zhen Lei's work: will try for the next
iteration, as a matter of course after the rebase. (And, looking at the
patch series at the top of modules-next, wow is that quite a hefty
performance improvement. And a hefty memory usage increase :( I have a
horrible feeling that one of my machines won't have enough memory to
boot after this goes in, but it was terribly outdated anyway.)
next prev parent reply other threads:[~2022-11-14 17:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 13:41 [PATCH PING v9] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms Nick Alcock
2022-11-09 13:41 ` [PATCH v9 1/8] kbuild: bring back tristate.conf Nick Alcock
2022-11-10 3:56 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 2/8] kbuild: add modules_thick.builtin Nick Alcock
2022-11-10 3:58 ` Luis Chamberlain
2022-11-11 13:47 ` Nick Alcock
2022-11-11 14:03 ` Nick Alcock
2022-11-11 15:12 ` Luis Chamberlain
2022-11-14 17:49 ` Nick Alcock
2022-11-15 21:21 ` Luis Chamberlain
2022-11-21 15:21 ` Nick Alcock
2022-11-21 19:12 ` Luis Chamberlain
2022-11-21 19:18 ` Luis Chamberlain
2022-11-21 21:14 ` Nick Alcock
2022-11-09 13:41 ` [PATCH v9 3/8] kbuild: generate an address ranges map at vmlinux link time Nick Alcock
2022-11-13 3:02 ` Luis Chamberlain
2022-11-14 16:48 ` Nick Alcock
2022-11-15 21:22 ` Luis Chamberlain
2022-11-16 16:06 ` Nick Alcock
2022-11-09 13:41 ` [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
2022-11-13 3:15 ` Luis Chamberlain
2022-11-14 17:04 ` Nick Alcock [this message]
2022-11-15 11:47 ` Leizhen (ThunderTown)
2022-11-15 13:25 ` Nick Alcock
2022-11-15 19:58 ` Luis Chamberlain
2022-11-15 20:36 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 5/8] kallsyms: optimize .kallsyms_modules* Nick Alcock
2022-11-09 13:41 ` [PATCH v9 6/8] kallsyms: distinguish text symbols fully using object file names Nick Alcock
2022-11-09 13:41 ` [PATCH v9 7/8] kallsyms: add /proc/kallmodsyms for text symbol disambiguation Nick Alcock
2022-11-13 3:26 ` Luis Chamberlain
2022-11-14 16:57 ` Nick Alcock
2022-11-15 21:24 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 8/8] perf: proof-of-concept kallmodsyms support Nick Alcock
-- strict thread matches above, loose matches on Subject: below --
2022-10-27 19:57 [PATCH v9] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms Nick Alcock
2022-10-27 19:57 ` [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
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=87mt8tv554.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=eugene.loh@oracle.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=rostedt@goodmis.org \
--cc=thunder.leizhen@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).