Re: [PATCH] new kallsyms approach

[Jan Beulich]

>I don't think it's a good idea to have two different ways
>to do kallsyms. Either we should always use your new
>way in standard KALLSYMS or not do it at all.

I agree, but I wanted to retain the old mechanism not the least because
of the space constraints you mention.

>The major decision factor is how much bloat it adds.
>Can you post before/after numbers of binary size? 

i386 vmlinux KALLSYMS_ALL=n: old=5782934 new=6106675 (5.60% increase)
i386 vmlinux KALLSYMS_ALL=y: old=6049118 new=6524411 (7.85% increase)
x86-64 vmlinux KALLSYMS_ALL=n: old=8593125 new=8962128 (4.30%
increase)
x86-64 vmlinux KALLSYMS_ALL=y: old=8797853 new=9117704 (3.64%
increase)

I shall note additionally that not using KALLSYMS_ALL with the new
approach increases the build time somewhat because the stripping of the
data symbols in this scheme is rather inefficient (a binutils limitation
as I would call it). KALLSYMS_ALL=y, however, is mostly suited for
kernel debugging, while KALLSYMS_ALL=n seems the best choice if just
caring about symbolic stack traces, which seems to be another argument
for keeping both mechanisms.

>If the difference is >5% or so - are there ways to recover
>the difference? 

There are certainly ways, but I'm not sure how much they would cost.
One thing would be to teach the linker to not only optimize the section
string table, but also the (normal) symbol string one. Decreasing the
symbol table size might be more difficult - only st_size and only on
64-bit archs seems to lend itself to reduction (as any symbol's size can
clearly be expected to be less than 4G). But that would result in
alignment problems, so I don't think that'd be a good idea either.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/