From: Tim Bird <tim.bird@am.sony.com>
To: linux kernel <linux-kernel@vger.kernel.org>
Subject: [Fwd: Recommendation for activating a deferred module init in the kernel]
Date: Tue, 17 Jun 2008 11:28:29 -0700 [thread overview]
Message-ID: <4858024D.6010601@am.sony.com> (raw)
Sorry - I meant to copy this to linux-kernel and forgot.
This is a query I just sent to the linux-embedded list.
Please copy linux-embedded@vger.kernel.org on any replies.
-------- Original Message --------
Subject: Recommendation for activating a deferred module init in the kernel
Date: Tue, 17 Jun 2008 11:23:18 -0700
From: Tim Bird <tim.bird@am.sony.com>
To: linux-embedded <linux-embedded@vger.kernel.org>
Hi all,
I am working with a product team on bootup time issues. One technique
that we are forward-porting from an old kernel (and that I thought I
might work on mainlining) is to compile modules statically into the kernel,
but defer their initialization until after boot time.
Normally, module init routines are declared with module_init(), which,
when they are statically linked into the kernel, uses the macro
__define_initcall() to add an entry to a special init segment.
This is called during bootup by do_initcall() (in init/main.c),
and the memory where the function resides is eventually freed.
There are several phases of initcalls (see include/linux/init.h),
including core, postcore, arch, subsys, fs, rootfs, device, and late.
In our modification, we:
1) add another phase for deferred initcalls
2) modify the module_init macro definition to use that phase, for the
modules we wish to defer initialization of
3) modify the free code to not free the memory until later
4) add an ioctl to trigger the deferred initialization (and memory free)
One of the main sub-systems that we defer initialization of this
way is USB, and this saves quite a bit of time. (Of course the
same, or slightly more CPU cycles are eventually used during
bootup time. But this lets us get to user space quicker so we
can start user-visible applications faster.)
I'm not that happy using an ioctl for this trigger. What is
the preferred method of activating a kernel feature like this?
I presume something in /proc or /sys, but I'm not sure.
Also, is there something like this in the kernel now that I'm
missing?
Any advice or comments would be welcome.
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
next reply other threads:[~2008-06-17 18:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 18:28 Tim Bird [this message]
2008-06-23 14:19 ` [Fwd: Recommendation for activating a deferred module init in the kernel] Pavel Machek
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=4858024D.6010601@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=linux-kernel@vger.kernel.org \
/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