Re: [PATCHv3 0/9] Mark literal strings in __init / __exit code

From: Joe Perches
Date: Sun Aug 24 2014 - 12:29:12 EST


On Sun, 2014-08-24 at 18:04 +0200, Mathias Krause wrote:
> On 21 August 2014 18:25, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
> > So is it really worth it?
>
> I took the hacky script mentioned in the first email (now also
> attached, init_str.awk), let it ran over the whole kernel, fixed the
> fall-out and did an allmodconfig build. Beside the script being far
> from perfect (it catches a few false positives and, more important,
> only covers a fraction of the potential strings -- only the pr_*()
> macros) it already leads to 24 modules requiring a page less during
> run-time because of the afore mentioned page crossing. It includes
> popular modules like hid.ko and ipv6.ko, so almost anybody would
> benefit from it. But as the page crossing effect depends on the
> particular kernel configuration and toolchain setup, fell free to do
> your own tests. The script doing the measurement is attached, too
> (mod_info.sh)

I think it would be worth it.

I think the added complexity converting:
printk/pr_<level>
to
pi_<level>/pe_<level>
for init/exit sections is a lightweight, one-time cost and
continuing upstream maintainer involvement is next to nil.

This mechanism supports all existing compiler toolchains.

Updating toolchains and or using a gcc compiler plugin
means that extra work would also need to be done for llvm
and any other alternate compiler.

And, as Mathias mentioned, the string deduplication logic
may be somewhat complicated for each compiler.

The worst that happens if a printk is added that is not
written as pi_<level> is some unnecessary .text is consumed.

No doubt someone will every so often run Mathias' scripts
against the kernel tree and submit the odd patch to fix it
up.


--
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/