On Mon, 2005-04-18 at 10:33 -0400, Tom Heydt-Benjamin wrote:
I followed with interest the "Boot Poster Challenge"
thread from
November. If I am correct, all of the profiling results that were
demonstrated were done in userland by instrumenting the rc files and such.
Yes, the early versions used to patch the sysinit script and use top and
iostat for collecting data. This was later changed by replacing init(1)
and collecting all data from /proc directly. See [1] for details.
Has anyone experimented with instrumenting the kernel to try and
get
fine grained profiling data from the earliest parts of the boot
process? I need to do this for some experiments that we are
performing with power management of small mobile Linux devices, and
before I re-invent the wheel, I want to know what wisdom is available
on collecting timing data from the kernel starting early in the boot
process.
Depending on what kind of data you're interested in (kernel boot or
user-space boot?), there are already a number of useful interfaces in
the kernel:
1. Profiling
Using readprofile or oprofile you can get some basic profiling
information. See linux/Documentation/basic_profiling.txt.
2. BSD process accounting
Process accounting will allow you to get a detailed picture of
the time and resources used by processes. By enabling
CONFIG_BSD_PROCESS_ACCT_V3 (which also requires an updated
user-space tool) you'll even get PID/PPID information, which is
great for creating the process dependency graph.
3. Audit
The audit subsystem in the 2.6 kernels provides system call
auditing. Since it also intercepts calls to path_lookup(), you
can use it to build a list of all opened files for example. Take
a look at the audit package in rawhide.
LTT[2] could also be used for tracing system calls. It used to
live in the -mm patchset, but I think it's currently being
reworked.
[1]
http://www.bootchart.org/docs.html
[2]
http://www.opersys.com/LTT/
--
Ziga