[U-Boot] [PATCH 3/8] boottime: Add core boottime measurement support

[Lee Jones]

On Wed, 21 Nov 2012, Wolfgang Denk wrote:

> Dear Lee Jones,
> 
> In message <20121121150332.GC28899 at gmail.com> you wrote:
> >
> > > Neither ATAGS not the device tree are intended nor designed for
> > > passing logfile information.  Yes, you can use them like that, and it
> > > will actually work.
> > 
> > ATAGs were exactly designed for this type of thing. To pass small
> > data structures though to the kernel. In our case, our trace-points
> > are held in a small data structure. They're not logs.
> 
> You appear to have a specific definition of log data in mind.  It must
> be different to mine.

I would say that a log entry would contain useful descriptive
information contained. It is _sometimes_ useful to display a related
timestamp too. In our case, the most useful part is the timestamp.
I just don't see how riddling the kernel log with timestamps would
be useful, or nessersary.

> Also, you contradict yourself - here you write "pass small data
> structures", earlier you wrote about "lots of trace-points", which
> sounds as if the total amount of data would be not exactly small -
> actually so big that yu are afraid of annoying users with it.

Right, perhaps I should have been more descriptive. I don't see the
bootloader passing lots of these trace points. The current
configuration will allow 10; however, the kernel logs one for every
cecal. This would quickly fill the kernel log with lots of
unwanted bumph. I also would like to store the data for bootloader
and kernel in the same manor. Placing the bootloader's trace points
in the kernel log, then putting the kernel's ones somewhere else
would add unwanted complexity. Especially if you're wanting the
user to write an app for parsing. I would prefer it if all of the
processing could be done in the kernel and displayed nicely via
debugfs.
 
> Anyway.  This doesn't take us further.
>
> > They're not poor augments if the data stored isn't log messages,
> > which these aren't. If anything I would say that ramming them in as
> > textual kernel messages, then parsing the log text using a userspace
> > tool was an abuse of the system. If we create them as data in the
> > bootloader, then pass them to the kernel as data, then process them
> > as data, _that_ would be the correct mechanism.
> 
> Well, I could pooint out here a number of pretty basic design
> decisions made earlier in a number of pretty important and successful
> software projects, like the fact that a large number of internet
> protocols are based on plain text implementations.  Or how useful it
> is if you can just to a post-mortem dump of the log buffer and
> actually _read_ the entries, without need to special tools.

You can do that in the current implementation though debugfs:

$ cat /sys/kernel/debug/boottime/bootgraph
[    0.023024] calling  board_init+0x0/0x0
[    0.177808] initcall board_init+0x0/0x0 returned 0 after 154 msecs.
[    0.177808] calling  main_loop+0x0/0x0
[    0.179632] initcall main_loop+0x0/0x0 returned 0 after 1 msecs.

It is your suggestion that would require _extra_ bespoke tools
for parsing and actually obtaining the information you require.
Where as we can just do this:

$ cat /sys/kernel/debug/boottime/summary 
bootloader: 5484 msecs
kernel: 2265 msecs
total: 7750 msecs
kernel: cpu0 system: 75% idle: 25% iowait: 0% irq: 0% cpu1 system: 2% idle: 97% iowait: 0% irq: 0%
bootloader: cpu0 system: 100% idle: 0% iowait: 0% irq: 0%

> I think I should stop here, though. It appears it makes little sense
> trying to discuss alternative approaches when you have already fixed
> your mind about the one and only "correct" way to do this.

Not at all. I am open to new and different approaches, so
long as they are better. I just don't agree that munging a
timestamp and id (usually a function name) into a text string
and shoving it into the kernel's log buffer is in any way
'better'.

I hope you can at least see my point.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog