Re: [PATCH v2 typo-fixed] initcall: add config option for compilinginitcall_debug

[Andrew Morton]

On Mon, 28 Mar 2011 11:51:31 +0400
Konstantin Khlebnikov <khlebnikov@xxxxxxxxxx> wrote:

> This patch adds bool config option CONFIG_INITCALL_DEBUG for
> compiling initcalls debuging, it on by default to keep current behaviour.
> 
> With CONFIG_INITCALL_DEBUG=n bloat-o-meter shows:
> 
> add/remove: 0/7 grow/shrink: 3/10 up/down: 88/-1448 (-1360)
> function                                     old     new   delta
> device_resume                                350     404     +54
> __device_suspend                             331     363     +32
> device_resume_noirq                          230     232      +2
> kernel_init                                  355     354      -1
> initcall_debug                                 4       -      -4
> __param_str_initcall_debug                    15       -     -15
> dpm_suspend                                  431     415     -16
> syscore_suspend                              280     250     -30
> syscore_shutdown                             123      93     -30
> __param_initcall_debug                        32       -     -32
> syscore_resume                               215     173     -42
> static.initcall_debug_start                   71       -     -71
> static.initcall_debug_report                 102       -    -102
> legacy_resume                                129       -    -129
> async_synchronize_cookie_domain              286     152    -134
> legacy_suspend                               135       -    -135
> async_run_entry_fn                           348     188    -160
> do_one_initcall                              364     197    -167
> pm_op                                        536     366    -170
> pm_noirq_op                                  576     366    -210

Well.  One hopes that most things which use initcall_debug are
marked __init or __initdata.

I see that async and pm have borrowed inticall_debug for reasonably
appropriate reasons, but I wonder if all that is permanent code, or if
it will later get removed.  Because if it gets removed, this patch
becomes rather pointless.

And the async code didn't try very hard anyway - it has a bunch of code
wired into .text which is only used at boot time.

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