| Age | Commit message (Collapse) | Author | Files |
|---|
|
commandline
Rather than hardcode the value of "8", allow the minimum task length to be
configured from the commandline using the -m option. "-m 0" means all
tasks will be graphed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If two entries have the same start time, the data store used will cause
all but one of the entries to be lost. This patch enhances the data
storage structure to avoid this problem and allow more than one
event to start at the same time.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Fix teh output filename to make it easy to use
* Add a default output format (svg)
* Fix the usage message
* Fix the version to v1.0.0
Currently, the help messages are:
$ ./pybootchartgui.py --help
Usage: pybootchartgui.py [options] /path/to/tmp/buildstats/<recipe-machine>/<BUILDNAME>/
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-i, --interactive start in active mode
-f FORMAT, --format=FORMAT
image format: svg, pdf, png, [default: svg]
-o PATH, --output=PATH
output path (file or directory) where charts are
stored
-s NUM, --split=NUM split the output chart into <NUM> charts, only works
with "-o PATH"
-n, --no-prune do not prune the process tree
-q, --quiet suppress informational messages
--very-quiet suppress all messages except errors
--verbose print all messages
[YOCTO #2403]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Split the output chart into multiple ones to make it more readable, it
only works with "-o path", which means that it doesn't work if the user
doesn't want to save the chart to the disk. For example:
$ ./pybootchartgui.py /path/to/tmp/buildstats/core-image-sato-qemux86/201205301810/ -f svg -s 5 -o /tmp/
bootchart written to /tmp/bootchart_1.svg
bootchart written to /tmp/bootchart_2.svg
bootchart written to /tmp/bootchart_3.svg
bootchart written to /tmp/bootchart_4.svg
bootchart written to /tmp/bootchart_5.svg
[YOCTO #2403]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The original patch is from Richard, I rebased it to the up-to-date
upstream code, here are the original messages from him:
We have just merged Beth's initial buildstats logging work. I was
sitting wondering how to actually evaluate the numbers as I wanted to
know "where are we spending the time?".
It occurred to me that I wanted a graph very similar to that generated
by bootchart. I looked around and found pyboootchartgui and then hacked
it around a bit and coerced it to start producing charts like:
http://tim.rpsys.net/bootchart.png
which is the initial "pseudo-native" part of the build. This was simple
enough to test with.
I then tried graphing a poky-image-sato. To get a graph I could actually
read, I stripped out any task taking less than 8 seconds and scaled the
x axis from 25 units per second to one unit per second. The result was:
http://tim.rpsys.net/bootchart2.png
(warning this is a 2.7MB png)
I also added in a little bit of colour coding for the second chart.
Interestingly it looks like there is more yellow than green meaning
configure is a bigger drain on the build time not that its
unexpected :/.
I quite enjoyed playing with this and on a serious note, the gradient of
the task graph makes me a little suspicious of whether the overhead of
launching tasks in bitbake itself is having some effect on build time.
Certainly on the first graph there are some interesting latencies
showing up.
Anyhow, I think this is the first time bitbake's task execution has been
visualised and there are some interesting things we can learn from it.
I'm hoping this is a start of a much more detailed understanding of the
build process with respect to performance.
[YOCTO #2403]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
This is from:
http://pybootchartgui.googlecode.com/files/pybootchartgui-r124.tar.gz
Will modify it to make the build profiling in pictures.
Remove the examples since they would not work any more, and they cost
much disk space.
[YOCTO #2403]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
