Hi All,
From UDS last week I was inspired to run bootchart on our Linaru
Ubuntu-desktop LEB.
I collected the data on my panda board using the daily snapshot from last week.
From a very quick examination of the output, it would seem we are IO bound.
I've created a quick wiki page about BootChart and attached the data I've gathered.
https://wiki.linaro.org/BootChart
Regards, Tom
Linaro Developer Platforms "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com irc) Dr_Who
Hi,
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Hi All,
From UDS last week I was inspired to run bootchart on our Linaru Ubuntu-desktop LEB.
I collected the data on my panda board using the daily snapshot from last week.
From a very quick examination of the output, it would seem we are IO bound.
I've created a quick wiki page about BootChart and attached the data I've gathered.
Interesting.
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
I wonder how a rotary disk attached to USB would compare...
---Dave
On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
Hi,
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Hi All,
From UDS last week I was inspired to run bootchart on our Linaru Ubuntu-desktop LEB.
I collected the data on my panda board using the daily snapshot from last week.
From a very quick examination of the output, it would seem we are IO bound.
I've created a quick wiki page about BootChart and attached the data I've gathered.
Interesting.
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
Um, why are we writing to anything on boot up?
(Or is it an artifact of recording the BootChart data?)
On Wed, May 18, 2011 at 3:32 PM, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
Hi,
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Hi All,
From UDS last week I was inspired to run bootchart on our Linaru Ubuntu-desktop LEB.
I collected the data on my panda board using the daily snapshot from last week.
From a very quick examination of the output, it would seem we are IO bound.
I've created a quick wiki page about BootChart and attached the data I've gathered.
Interesting.
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
Um, why are we writing to anything on boot up?
I'm just guessing there might be _some_ writes -- from atime updates, logfile writes and corresponding journal writes for example -- and if so there then it may be having a significant impact. We could check the actual I/O to be sure.
On graphical login, various daemons may scribble in dot dirs and databases -- find -mmin could help here.
(Or is it an artifact of recording the BootChart data?)
Possible ... I would hope that the boothchart data goes into a ramfs to avoid that. Worth checking, though.
Cheers ---Dave
+++ Christian Robottom Reis [2011-05-18 11:32 -0300]:
On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
Hi,
Um, why are we writing to anything on boot up?
Daemons writing their pids to /var/run, is one example. One advantage of plan to move /run to root and make it a tmpfs.
Wookey
On 18 May 2011 16:53, Dave Martin dave.martin@linaro.org wrote:
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
The long time of "mount" looks fishy. Are you sure you are booting with a clean filesystem?
Other than that we see that
1) we start too much (cron, gdm, ...) for our use case 2) too many shells started to parse shell scripts
As for finding files writes to on boot, using a "find / -mtime -2" or some variation to pick up files modified since boot is easiest.
On Wed, May 18, 2011 at 3:39 PM, Riku Voipio riku.voipio@linaro.org wrote:
On 18 May 2011 16:53, Dave Martin dave.martin@linaro.org wrote:
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
The long time of "mount" looks fishy. Are you sure you are booting with a clean filesystem?
Other than that we see that
- we start too much (cron, gdm, ...) for our use case
- too many shells started to parse shell scripts
perf can do system-wide profiling to find how much time is spent in different libraries / binaries.
---Dave
As for finding files writes to on boot, using a "find / -mtime -2" or some variation to pick up files modified since boot is easiest.
The long time of "mount" looks fishy. Are you sure you are booting with a clean filesystem?
Other than that we see that
- we start too much (cron, gdm, ...) for our use case
- too many shells started to parse shell scripts
As for finding files writes to on boot, using a "find / -mtime -2" or some variation to pick up files modified since boot is easiest.
You can also to keep rootfs read only (ro in cmdline and don't remount it with rw) to track redundant writes.
On Wed, May 18, 2011 at 11:39 AM, Riku Voipio riku.voipio@linaro.org wrote:
On 18 May 2011 16:53, Dave Martin dave.martin@linaro.org wrote:
On Tue, May 17, 2011 at 5:53 PM, Tom Gall tom.gall@linaro.org wrote:
Due to the poor I/O throughput, it looks a bit like we might be hitting the known SD card write behaviour issues; mounting with noatime and/or journaling disabled (noload for ext4) might also make a difference.
The long time of "mount" looks fishy. Are you sure you are booting with a clean filesystem?
Other than that we see that
- we start too much (cron, gdm, ...) for our use case
That's because we're using the ubuntu-netbook task, that brings a lot of additional daemons.
- too many shells started to parse shell scripts
I can see a lot of 'sh', 'cat', 'rm', 'sleep', 'run-parts', I think this could all be optimized.
As for finding files writes to on boot, using a "find / -mtime -2" or some variation to pick up files modified since boot is easiest.
Yeah, would be good to see what was actually changed at the filesystem. Having the bootchart with a usb driver can also help comparing the results.
Cheers,
On Wed, May 18, 2011 at 02:48:25PM -0300, Ricardo Salveti wrote:
- too many shells started to parse shell scripts
I can see a lot of 'sh', 'cat', 'rm', 'sleep', 'run-parts', I think this could all be optimized.
"run-parts" here is surprising; I'm not aware of anything that should call this in the normal boot sequence. The closest I can think of is update-motd, but that should only trigger as part of a login session, not with an autologin.
I think digging into this further will turn up a bug...
On Thu, May 19, 2011 at 02:20:59PM -0700, Steve Langasek wrote:
On Wed, May 18, 2011 at 02:48:25PM -0300, Ricardo Salveti wrote:
- too many shells started to parse shell scripts
I can see a lot of 'sh', 'cat', 'rm', 'sleep', 'run-parts', I think this could all be optimized.
"run-parts" here is surprising; I'm not aware of anything that should call this in the normal boot sequence. The closest I can think of is update-motd, but that should only trigger as part of a login session, not with an autologin.
I think digging into this further will turn up a bug...
Is run-parts used to run legacy sysvinit scripts, or is that handled by something else?
Cheers ---Dave
On Fri, May 20, 2011 at 11:32:21AM +0100, Dave Martin wrote:
On Thu, May 19, 2011 at 02:20:59PM -0700, Steve Langasek wrote:
On Wed, May 18, 2011 at 02:48:25PM -0300, Ricardo Salveti wrote:
- too many shells started to parse shell scripts
I can see a lot of 'sh', 'cat', 'rm', 'sleep', 'run-parts', I think this could all be optimized.
"run-parts" here is surprising; I'm not aware of anything that should call this in the normal boot sequence. The closest I can think of is update-motd, but that should only trigger as part of a login session, not with an autologin.
I think digging into this further will turn up a bug...
Is run-parts used to run legacy sysvinit scripts, or is that handled by something else?
/etc/init.d/rc (and/or startpar) does its own sequencing of init scripts, run-parts is too generic to do the job.
-
Christian Robottom Reis -
Constantine Shulyupin -
Dave Martin -
Ricardo Salveti -
Riku Voipio -
Steve Langasek -
Tom Gall -
Wookey