Thread (14 messages) flat view 14 messages, 5 authors, 2011-09-27

[RFC PATCH 0/3] Add accurate boot timing to a Linux system

From: sjg@chromium.org (Simon Glass)
Date: 2011-09-27 18:42:12
Also in: lkml

Hi Tim,

On Tue, Sep 27, 2011 at 10:56 AM, Tim Bird [off-list ref] wrote:
On 09/23/2011 04:03 PM, Simon Glass wrote:
quoted
This experimental patch set adds boot timing to a Linux system. The
timing starts with the boot loader and extends through the kernel into
user space to the completion of the boot process. The timing starts when
the system leaves reset, not later when the kernel starts.
I would be very interested in this. ?This is something that
would be very helpful, I believe, to assist with optimizing
overall boot time.
Good.
quoted
Finally, in user space there is no kernel-blessed way to record
timestamps. One approach is to add lines to the init scripts like
'cat /proc/uptime >/tmp/login_starts'.
This creates another place where
the boot timing tool must look for information.
'cat /proc/uptime >/dev/kmsg' (with printk timestamps on) is much
better than the above, for this reason.
Yes, although this needs root access on my machine. Am hoping to have
something easily accessible from user space.
quoted
This Patchset
-------------
This patchset aims to unify timing in one place: a simple driver which
collects pre-kernel boot timestamps, adds its own as it boots, with
calls to bootstage_mark(), then allows user space (init, etc.) to add
more with 'echo "message" >>/sys/kernel/debug/bootstage/mask'.

Finally it permits user space to access the full list of timestamps
with 'cat /sys/kernel/debug/bootstage/report', which has two columns:
the stage name and the timestamp:

? ? ? reset ? 0
? ? ? arch_cpu_init-AVP ? ? ? 258902
? ? ? arch_cpu_init-A9 ? ? ? ?263267
? ? ? arch_cpu_init-done ? ? ?263312
? ? ? board_init_f-start ? ? ?263314
? ? ? board_init_r-start ? ? ?323671
? ? ? main_loop ? ? ? 573008
...

I would prefer the timestamp in the first column. ?Also, for consistency
it would be good if it used the same format as printk timestamps:
"[%5lu.%06lu]" with seconds and micro-seconds in the respective fields.
Then, existing tools like scripts/show_delta and scripts/bootgraph.pl
could work on this data as well.
Yes that makes sense, I will adjust it.
Full micro-second granularity is not required, but it's nice to keep
the format the same, whether the clock supports it or not.
Yes, and it's surprising how often microsecond accuracy is useful. For
example, recently I was looking at the impact of reduced
voltage/frequency early in boot on an ARM platform. The difference was
only a few ms, and the microsecond timer resolution helped a lot in
seeing the impact of these changes.
Finally, is this work related at all to this:
http://lists.denx.de/pipermail/u-boot/2011-September/099996.html
Bootgraph.pl instrumentation support for UBoot
??

Just wondering.
It is related in the sense that ideally all of this would come
together and play nicely. That's an interesting patch also, and there
are a few threads to tie together in U-Boot independently of the
kernel.

My original U-Boot patch set was here:

http://lists.denx.de/pipermail/u-boot/2011-May/092584.html
Thanks - this looks like great stuff!
Thanks!

Regards,
Simon
?-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help