From: Eugene Loh <eugene.loh@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Jonathan Corbet <corbet@lwn.net>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <michal.lkml@markovi.net>,
Jessica Yu <jeyu@kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Marc Zyngier <maz@kernel.org>, Song Liu <songliubraving@fb.com>,
Thomas Gleixner <tglx@linutronix.de>,
jacob.e.keller@intel.com,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kris Van Hees <kris.van.hees@oracle.com>,
Nick Alcock <nick.alcock@oracle.com>
Subject: Re: [PATCH] kallsyms: new /proc/kallmodsyms with builtin modules and symbol sizes
Date: Tue, 19 Nov 2019 16:11:02 -0800 [thread overview]
Message-ID: <e802475d-512a-77fb-9146-4b575df1f916@oracle.com> (raw)
In-Reply-To: <CAHk-=wjoXE1tRVVwgDY=G8xXKCAxz8mfYBaTh8wF=QTFPRwmJQ@mail.gmail.com>
On 11/16/2019 04:32 PM, Linus Torvalds wrote:
> On Sat, Nov 16, 2019 at 9:58 AM Eugene Loh <eugene.loh@oracle.com> wrote:
>> Since there are very many gaps, adding dummy entries makes sense only
>> for "big" jumps. I don't know where one would want to draw the line for
>> "big." In any case, to identify such gaps, one would still need the "nm
>> -S" information provided by this patch.
> Sure. You can have some kind of error estimate where if the size of
> the thing is much smalle rthan the gap, add the fake padding object.
>
> But it "much smaller than" would likely be in the area of page
> alignment, not "next function was aligned to 64-byte boundary" kind of
> small fixups.
>
> Honestly, if somebody needs the real size, why aren't they just using
> the original image?
>
>> Meanwhile, there are some symbols that encompass others.
> Yeah, I don't think this is at all worth worrying about. Again, if you
> want that kind of information, you should use the original vmlinux
> image, not think that "hey, /proc should give perfect information".
We're also interested in systems that don't have vmlinux available --
e.g., production systems with kernels installed from vendor packages.
Nevertheless, I'll proceed along the lines you suggest. I'll remove the
size stuff and simply add the module info. I prematurely sent a "v2" to
this mail list. Sorry. Amended patch coming soon.
> The /proc interface should be a rought and convenient baseline, but I
> don't think it's at all interesting to try to make it perfect or even
> all that clever.
>
> Most of your questions boil down to "just use vmlinux" instead. If you
> _really_ care about things like "one symbol can encompass many
> sub-symbols", you shouldn't look at /proc/kallsyms.
>
> So I think we could improve on /proc/kallsuyms, but we should do it
> with the aim being "just make it incrementally better", not some
> "let's solve big problems". The big problems are already solved by
> just looking at the vmlinux file.
>
> For example, I think the whole "include which module the symbol comes
> from" is a nice improved quality thing even if the module happens to
> be built-in. If that is easy to do, then we should just do it, and it
> allows people to see interesting information and might make it useful
> to (for example) have tools like profiling be able to zoom into
> particular "modules", even if the module is built-in.
>
> And if there are big gaps that aren't just "align to next cacheline",
> then that sounds like it's worth pointing out too.
>
> But I see _zero_ reason not to say "just use vmlinux if you need
> detailed information". The /proc file is not supposed to be a
> replacement for the full setup, it should be seen as a convenient
> shorthand and as a "if you have nothing better, at least you can get
> _some_ information, and maybe you can also use it to validate that you
> have the _right_ vmlinux file"
>
> Linus
prev parent reply other threads:[~2019-11-20 0:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-14 22:30 [PATCH] kallsyms: new /proc/kallmodsyms with builtin modules and symbol sizes eugene.loh
2019-11-15 16:47 ` Steven Rostedt
2019-11-15 17:26 ` Linus Torvalds
2019-11-16 17:58 ` Eugene Loh
2019-11-17 0:32 ` Linus Torvalds
2019-11-19 22:42 ` [PATCH v2] kallsyms: add names of built-in modules eugene.loh
2019-11-20 4:59 ` [PATCH v3] " eugene.loh
2019-11-22 10:00 ` Masahiro Yamada
2019-11-22 15:23 ` Nick Alcock
2019-11-22 17:04 ` Eugene Loh
2019-12-10 17:45 ` Eugene Loh
2019-12-10 17:48 ` [PATCH v4] " eugene.loh
2019-12-18 23:55 ` Eugene Loh
2019-12-19 3:29 ` Steven Rostedt
2019-12-19 4:28 ` Masahiro Yamada
2019-12-19 10:22 ` Masahiro Yamada
2020-01-08 18:32 ` Eugene Loh
2020-01-20 6:37 ` Masahiro Yamada
2020-01-24 18:08 ` Eugene Loh
2019-12-19 9:43 ` Jessica Yu
2019-11-20 0:11 ` Eugene Loh [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=e802475d-512a-77fb-9146-4b575df1f916@oracle.com \
--to=eugene.loh@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=jacob.e.keller@intel.com \
--cc=jeyu@kernel.org \
--cc=kris.van.hees@oracle.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=maz@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nick.alcock@oracle.com \
--cc=rostedt@goodmis.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yamada.masahiro@socionext.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