Proposal: fastboot parameter cache for Linux


Tim Bird <tim.bird@...>
 

Fastboot parameter cache for Linux

; Summary: Fastboot parameter cache for Linux

; Proposer: Tim Bird

== Description ==
This proposal would be the creation and mainlining of a fastboot
parameter cache for the Linux kernel.

The purpose of this cache would be to store values which are
detected in one boot of the Linux kernel, so they can be
quickly accessed and used on subsequent boots of the kernel,
to reduce kernel initialization time (specifically, to avoid
unneeded probing for non-changing hardware.)

The idea would be to provide an internal facility (API)
inside the kernel that drivers could use to query for
hardware parameters, prior to probing. If a value is found,
then the probe can be avoided. If not, then probing is
done as usual. It would be important to have a very unintrusive and
easy-to-use API for this.

The mechanism would need to support a method of persistently storing
the values for future kernel invocations (for example, by storing
them in persistent memory, in a device tree, passing them on the
kernel command line, or attaching them to the kernel boot image)

This can be seen as a generalization of the way probing/autodetection
is avoided by using a command line parameter for loops_per_jiffy.

Andrew Murray proposed this under the name "boot cache", in August, 2010
to the kernel mailing list.

== Related work ==
* See Andrew Murray's talk at ELC Europe 2010 - The Right Approach to Minimal Boot Times
** http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf
* See [[Preset LPJ]] for a description of how preset loops_per_jiffy works
* Andrew Murray's RFC and discussion on LKML:
** See https://lkml.org/lkml/2010/8/31/347

== Scope ==
The mechanism could probably be developed in 4 to 8 weeks. Mainlining it
might take 4 to 6 additional weeks.

== Contractor Candidates ==

== Comments ==

[[Category:Project proposals 2011]]


wu zhangjin
 

Hi, Tim

This is really a wonderful idea, I have thought something similar
today, except caching the parameters in some place, we may be possible
to ask gcc to re-compile the kernel with these parameters(or we can
call them 'run time statistic data') and eliminate some of the
unnecessary branches and calling paths.

To record the persistent parameters at run-time, we may be possible to
mark those parameters as __runtime_fixed and put them into one section
__runtime_fixed_param, once running the kernel, those parameters can
be dumped out with a standard interface(/proc or /sys?), some of them
can be stored in some place and the others can be used to re-compile
the kernel.

For the persistent parameters, the variables marked as __read_mostly
can the candidates, but may be not most of them. so, this may need the
kernel developers carefully mark the variables as __runtime_fixed to
get better optimization.

For the re-compiling stuff, the MIPS specific cpu-feature-overrides.h
strategy is really a good example, lots of macros have been defined in
a common cpu-features.h, e.g.:

#ifndef current_cpu_type
#define current_cpu_type() current_cpu_data.cputype
#endif

If no static definition of current_cpu_type defined in the board's
cpu-feature-overrides.h, the probed value will be used and the probing
is necessary, otherwise, the related branches and calling paths will
be optimized by the compiler. As a result, both of the boot time and
kernel image size will be saved.

Currently, in mainline linux-MIPS, this cpu-feature-overrides.h is
added by users manually, but why not provide an interface to dump them
out? yup, we can, I added a new kernel config and allow users to dump
the macros for cpu-feature-overrides.h automatically via the
traditional /proc/cpuinfo interface:
http://dev.lemote.com/cgit/linux-loongson-community.git/commit/?h=tiny36&id=56ab52376298dee38aeb27d065c1a20ef94739c3

But perhaps we can take one step ahead, that is we can mark more
run-time-persistent variables as __runtime_fixed(is this name okay?)
and dump them out, cache them for kernel to avoid probing or
re-compile the kernel with them for further optimization.

BTW, I will send a proposal about "Linux-Tiny for MIPS", I have
already done some work on it, that is:

http://dev.lemote.com/cgit/linux-loongson-community.git/log/?h=tiny36

I have forward ported most of the Linux-tiny patches from 2.6.23 to
2.6.36, has made --gc-sections -ffunction-sections -fdata-sections
work on MIPS, and also, some MIPS specific size & boot time reducing
methods has been applied: allow the software or hardware fpu support
be configurable, add more macros in cpu-features.h and allow the users
to dump out the macros and get a cpu-feature-overrides.h
automatically. The next step is trying to make -fwhole-program -flto
work instead of the old -fwhole-program -combine(gcc doesn't work well
with __attribute__((externally_visible))).

Best Regards,
Wu Zhangjin

On Fri, Jan 7, 2011 at 9:01 AM, Tim Bird <tim.bird@...> wrote:
Fastboot parameter cache for Linux

; Summary: Fastboot parameter cache for Linux

; Proposer: Tim Bird

== Description ==
This proposal would be the creation and mainlining of a fastboot
parameter cache for the Linux kernel.

The purpose of this cache would be to store values which are
detected in one boot of the Linux kernel, so they can be
quickly accessed and used on subsequent boots of the kernel,
to reduce kernel initialization time (specifically, to avoid
unneeded probing for non-changing hardware.)

The idea would be to provide an internal facility (API)
inside the kernel that drivers could use to query for
hardware parameters, prior to probing.  If a value is found,
then the probe can be avoided.  If not, then probing is
done as usual.  It would be important to have a very unintrusive and
easy-to-use API for this.

The mechanism would need to support a method of persistently storing
the values for future kernel invocations (for example, by storing
them in persistent memory, in a device tree, passing them on the
kernel command line, or attaching them to the kernel boot image)

This can be seen as a generalization of the way probing/autodetection
is avoided by using a command line parameter for loops_per_jiffy.

Andrew Murray proposed this under the name "boot cache", in August, 2010
to the kernel mailing list.

== Related work ==
* See Andrew Murray's talk at ELC Europe 2010 - The Right Approach to Minimal Boot Times
** http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf
* See [[Preset LPJ]] for a description of how preset loops_per_jiffy works
* Andrew Murray's RFC and discussion on LKML:
** See https://lkml.org/lkml/2010/8/31/347

== Scope ==
The mechanism could probably be developed in 4 to 8 weeks.  Mainlining it
might take 4 to 6 additional weeks.

== Contractor Candidates ==

== Comments ==

[[Category:Project proposals 2011]]

_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
http://tree.celinuxforum.org/mailman/listinfo/celinux-dev