performs poorly on slow HDD

[Scott James Remnant (Canonical)]

Binary package hint: sreadahead

This is a tracking bug to improve performance on HDD disks, especially the really slow ones where sreadahead and the kernel have a deathmatch

[Martin Pitt (pitti)]

Speaking of which, is it actually deliberate that sreadahead runs for a very long time, without doing anything CPU/IO related at all? (see http://people.canonical.com/~pitti/tmp/tick-karmic-20090916-2.png for example).

[Scott James Remnant (Canonical) (canonical-scott)]

This may end up being a lynx project, it does not seem to be a simple "fix".

The recent change to the deadline scheduler has certainly improved things though

[Matej Kenda (matejken)]

Is this in any way related to bug 421116, which was fixed recently?

[Martin Pitt (pitti)]

Bug 421116 was about taking a lot of CPU for building the pack. As far as I understand, this bug is about sreadahead not doing any actual readahead (or doing it poorly) on startup when it already has a pack?

[Martin Pitt (pitti)]

E. g. here: http://people.canonical.com/~pitti/tmp/tick-karmic-20090924-2.png

Runs for a long time without doing any CPU/IO

[Robbie Williamson (robbiew)]

@Scott: Could you put in a summary of the current status for this bug please. Thanks

[Paul Sladen (sladen)]

Keybuk: how long *should* sreadahead be running for? Times of ~30 seconds runtime for sreadahead appear to be "normal" charts on (see bug #423924).

[Rami Al-Rfou' (rmyeid)]

I attached the bootchart with sreadahead enabled and disabled.
I disabled sreadahead by commenting the exec statement
exec /sbin/sreadahead -t 0
in /etc/init/sreadahead.conf

[Johan Kiviniemi (ion)]

Is this the correct bug report for this issue? On my quite new laptop (dualcore 2.2 GHz AMD CPU, 3 GiB of RAM, a 320 GB HDD), sreadahead consistently slows startup down by about 5.5 seconds.

I measured this with the following job:

start on login-session-start
task
script
    cat /proc/uptime >>/uptimes
    if [ "$(wc -l /uptimes | cut -d' ' -f1)" -lt 5 ]; then
        reboot
    fi
end script

The average measured time with sreadahead disabled is 33.07 s, and with sreadahead enabled, 38.55 s.

Could something as simple as making the rest of the startup wait for sreadahead to finish fix this? The problem might simply be caused by thrashing when sreadahead is doing its thing simultaneously with the rest of the system booting.

[Pavel Rojtberg (rojtberg)]

in case this bug cant be fix for karmic - are there any plans to revert to readahead and postpone sreadahead for lynx? It did a good job for HDDs and these are still used in the majority of the target systems.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-10-14 at 21:40 +0000, Pavel Rojtberg wrote:

> in case this bug cant be fix for karmic - are there any plans to revert
> to readahead and postpone sreadahead for lynx? It did a good job for
> HDDs and these are still used in the majority of the target systems.
>
In the testing I've been able to do, readahead doesn't show any
improvement.

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

Scott James Remnant [2009-10-15 17:38 -0000]:
> In the testing I've been able to do, readahead doesn't show any
> improvement.

Hm, sreadahead does not do _any_ readahead for me right now. Is that
due to a kernel change which would also break readahead?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-10-15 at 18:53 +0000, Martin Pitt wrote:

> Scott James Remnant [2009-10-15 17:38 -0000]:
> > In the testing I've been able to do, readahead doesn't show any
> > improvement.
>
> Hm, sreadahead does not do _any_ readahead for me right now. Is that
> due to a kernel change which would also break readahead?
>
Not that I know of - which kernel are you using?

Scott
--
Scott James Remnant
<email address hidden>

[Hernando Torque (htorque)]

@Martin Pitt: Are you referring to the bar in the chart not being red? Maybe bootchart doesn't represent sreadahead very well, because when put in foreground you can see I/O going on while the bar is still gray: http://img.xrmb2.net/images/660462.png

[Martin Pitt (pitti)]

Scott James Remnant [2009-10-15 19:43 -0000]:
> Not that I know of - which kernel are you using?

Just what's in karmic (amd64 2.6.31-14.47-generic), but it's been that
slow for weeks, so it's nothing new.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Martin Pitt (pitti)]

Hernando Torque [2009-10-15 21:17 -0000]:
> @Martin Pitt: Are you referring to the bar in the chart not being red?

I did yes. That, and grub->gdm now taking 85 seconds, where it took
just 50 in jaunty.

> Maybe bootchart doesn't represent sreadahead very well, because when put
> in foreground you can see I/O going on while the bar is still gray:
> http://img.xrmb2.net/images/660462.png

It might also be a bootchart bug of course, assigning the I/O to wrong
processes. However, I don't quite believe that: As you see in my
bootchart [1], sreadahead starts and just has a tiny fraction of a
second before other processes kick in and use I/O. In the readahead
times it was the only active process for some 15 seconds, to avoid
trashing with other processes.

Martin

[1] http://people.canonical.com/~pitti/tmp/tick-karmic-20090924-2.png
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[papukaija (papukaija)]

Is it possible to fix this bug before the final release of Karmic?

[Steve Langasek (vorlon)]

No, there's no way this will be fixed before final release. Redirecting to the SRU queue.

[Scott James Remnant (Canonical) (canonical-scott)]

Please try the following:

  sudo add-apt-repository ppa:ubuntu-boot/ppa
  sudo apt-get update
  sudo apt-get dist-upgrade

This should install an updated kernel package, and replace sreadahead with ureadahead.

The first reboot will reprofile your system, the second reboot should be substantially faster.

Please let me know how you get in (before/after bootcharts always appreciated)

[smooth (hsavio)]

The boot time did improve by ~ 5 Secs, which is faster but not substantially.
Also disk utilization has also dropped

I have attached the new bootchart.

[Martin Pitt (pitti)]

Scott,

it's working magnificiently here. Times from grub to gdm with no CPU/IO:

Default karmic (sreadahead): 57 seconds (http://people.canonical.com/~pitti/bootcharts/karmic-sreadahead.png)
Karmic without any *readahead: 45 seconds (http://people.canonical.com/~pitti/bootcharts/karmic-noreadahead.png)
Karmic with your PPA: 25 seconds (http://people.canonical.com/~pitti/bootcharts/karmic-ureadahead.png)

[Scott James Remnant (Canonical) (canonical-scott)]

This has been uploaded to karmic-proposed, since the kernel patch is there (though that might take some more cooking due to other patches in the kernel upload):

Changes:
 ureadahead (0.90.3-2) karmic-proposed; urgency=low
 .
   * über-readahead is a replacement for sreadahead that should
     significantly improve boot performance on rotational hard drives,
     especially those that had regressed in performance from jaunty to
     karmic.
 .
     It does this by pre-loading such things as ext2/3/4 inodes and opening
     files in as logical order as possible before loading all blocks in one
     pass across the disk.
 .
     On SSD, this behaves much as sreadahead used to, replacing that package
     with slightly improved tracing code.
 .
     This requires the kernel package also found in karmic-proposed.
 .
     LP: #432089.

[fossfreedom (fossfreedom)]

things improved here - if assuming I've read my boot chart correctly - from boot to GDM originally was 73 secs - with the PPA + ureadahead - 42 secs

[Rami Al-Rfou' (rmyeid)]

I attached below two boot charts one is before the update and the another is after. As I do not know how to interpret the bootcharts, I used my old wrest watch to calculate the boot times:

1-sreadahead
Grub-> GDM 35 seconds
GDM -> Ubuntu 45 seconds

2-ureadahead
Grub -> GDM 30 seconds
GDM -> Ubuntu 20 seconds (at most maybe less)

I still remember that it was working faster than this when I installed karmic alpha 3.

[Ryan (ubuntu-draziw)]

One more reboot since I saw fsck showing for a lot of the time on the last long boot. This is another ureadahead boot - 2 seconds faster than the prior sreadahead. (But still - 1:30 on a dual 2 ghz system)

[pbrufal (pbrufal)]

In my system, adding the PPA+ureadahead makes the system 5sec slower :? I'm using the last kernel (2.6.31-15.49)

80 sec before PPA
85 sec after PPA (tried 6 times)

[Martin Pitt (pitti)]

I accepted the source package into karmic-proposed, source NEWed. Will do "please verify" steps once it's through binary NEW.

[Martin Pitt (pitti)]

Accepted ureadahead into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 06:09 +0000, pbrufal wrote:

> In my system, adding the PPA+ureadahead makes the system 5sec slower :?
> I'm using the last kernel (2.6.31-15.49)
>
> 80 sec before PPA
> 85 sec after PPA (tried 6 times)
>
You didn't attach the "before" bootchart.

In the "after" bootchart, the boot time is actually only 55s; of which
it looks like 5s are waiting at the login screen.

Scott
--
Scott James Remnant
<email address hidden>

[FriedChicken (domlyons)]

After installing ureadahead from proposed booting takes about 10 s longer.

[Tyson Williams (bender2k14)]

This proposed update did not speed up my system (that uses a SSD).

Before update (~65 seconds): http://dl.dropbox.com/u/123623/Ubuntu/tyson-laptop-karmic-20091110-2.png
First boot after update(~60 seconds): http://dl.dropbox.com/u/123623/Ubuntu/tyson-laptop-karmic-20091110-3.png
Second boot after update (~65 seconds): http://dl.dropbox.com/u/123623/Ubuntu/tyson-laptop-karmic-20091110-4.png

In all of these boot charts, you can see that there is about a 30 seconds period where the CPU is barely being used, the CPU is waiting for the disk, the disk is being "utilized", but the throughput of the disk is basically zero. What is going on during this time? If it could be removed, I could at least get back to my ~30 Jaunty boot times.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 14:25 +0000, FriedChicken wrote:

> After installing ureadahead from proposed booting takes about 10 s
> longer.
>
From the chart, it actually appears a few seconds quicker - but it's
strange that it hasn't made much of a difference for you.

Try removing that /var/lib/ureadhead/*pack files then doing a boot with
auto-login enabled to profile that. If that's not faster - attach the
output of "ureadahead --dump" to this bug.

Scott
--
Scott James Remnant
<email address hidden>

[tado (r-launchpadtranslator-riseup-net)]

my boot time has decreased a bit, but it is still substantially high. bootchart says 1:20, my stopwatch says 1:52 till ready desktop.
unfortunately i don't have a bootchart from right before installing, so the one attached here is from a few days ago. no substantial changes have happened since then, anyway.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 15:42 +0000, Tyson Williams wrote:

> This proposed update did not speed up my system (that uses a SSD).
>
Ok, SSD gains are in the order of quarter to half a second - it's good
to know it hasn't regressed :p (this update is all about HDD
performance, not SSD)

> In all of these boot charts, you can see that there is about a 30
> seconds period where the CPU is barely being used, the CPU is waiting
> for the disk, the disk is being "utilized", but the throughput of the
> disk is basically zero. What is going on during this time? If it could
> be removed, I could at least get back to my ~30 Jaunty boot times.
>
hdparm sync of death. I should file a bug about that ;)
- delete /lib/udev/rules.d/85-hdparm.rules

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 16:43 +0000, tado wrote:

> my boot time has decreased a bit, but it is still substantially high. bootchart says 1:20, my stopwatch says 1:52 till ready desktop.
> unfortunately i don't have a bootchart from right before installing, so the one attached here is from a few days ago. no substantial changes have happened since then, anyway.
>
You're on SSD? Run "ureadahead --dump | head -2" for me and attach the
output.

Scott
--
Scott James Remnant
<email address hidden>

[Ryan (ubuntu-draziw)]

My before and after hover right around 131s tried remove on *pack, and did two more reboots. Here's the ureadahead --dump dump in case it is of any interest.

[FriedChicken (domlyons)]

Ignoring some smaller tasks (mainly network manager and related tasks) the boot is done in less than 92s. I don't know if that's what you expected (with sreadahead ist took about 98.5s without auto-login), but it is a clearly a speedup.

Deactivating the screensaver (kasciiaquarium) saves two seconds. Downside: Unless the mouse isn't moved to show the password prompt, the screen keeps black and you don't know if KDE has started yet or not.
So to get correct measurements two seconds have to be subtracted, but for me this isn't practical for everydays use.

[FriedChicken (domlyons)]

In case you need it...
Everything in the list has 0 blocks.

Thank you for your work!

[Ken VanDine (ken-vandine)]

I don't have a sane before bootchart, but I do know that the IO wait chart was staying pretty busy all the way up to the end (about 65s). Also before this update, the desktop was loading after xsplash timed out, and it was rather "chunky" loading.

After ureadahead 0.90.3-1 and linux-image-2.6.31-15-generic 2.6.31-15.50, the desktop is completely loaded before xsplash hides. And xsplash is actually relatively smooth, I only noticed one place where the animation stuttered.

Attached the after bootchart.

[Tyson Williams (bender2k14)]

>Ok, SSD gains are in the order of quarter to half a second - it's good to know it hasn't regressed :p (this update is all about HDD performance, not SSD)

I am posting in this bug report because the bug report (Bug #464369) that I was previously subscribed to (which was not specific to HDD or SSD) was declared to be a dup of this bug.

>hdparm sync of death. I should file a bug about that ;)
>- delete /lib/udev/rules.d/85-hdparm.rules

Deleting the hdparm worked in the sense that hdparm and sync no longer take any visible time (I can't find them in the boot chart...I don't think they are there), but I still have the same boot time with the same disk utilization with near zero throughput:
http://dl.dropbox.com/u/123623/Ubuntu/tyson-laptop-karmic-20091110-8.png

Let me know if you decided to create another bug report.

[dan50 (dancardona50)]

How to shave 45 seconds from your bootchart .. for karmic

Code:
sudo nano /etc/init/bootchart.conf

comment out this section
Code:
#pre-stop script
    # Sleep for an extra 45s to allow enough time to chart the desktop
    # login
# [ "$UPSTART_STOP_EVENTS" = "stopped" ] && sleep 45
#end script

[dan50 (dancardona50)]

file:///var/log/bootchart/cobra-karmic-20091110-4.png

file:///var/log/bootchart/cobra-karmic-20091110-5.png

[dan50 (dancardona50)]

cobra-karmic-20091110-4.png 56.6s
cobra-karmic-20091110-5.png 11.46s

[tado (r-launchpadtranslator-riseup-net)]

On Tue, 2009-11-10 at 16:43 +0000, tado wrote:

> my boot time has decreased a bit, but it is still substantially high. bootchart says 1:20, my stopwatch says 1:52 till ready >desktop.
> unfortunately i don't have a bootchart from right before installing, so the one attached here is from a few days ago. no >substantial changes have happened since then, anyway.
>
>You're on SSD? Run "ureadahead --dump | head -2" for me and attach the
>output.
>
>Scott

here is the output

[Jamie Lawler (jamie-lawler)]

Really fantastic work on ureadahead. Reduced my time to desktop from about 65s to 40 (would probably be more like 35 if gnome-do didn't lay idle for 5s before doing anything).

Now this is a bit of a guess: with my system now booting so fast, the 45s added for bootchart logging mean that bootchart logs for about 30s after I'm fully logged in. I have no issues with this.
I decided to boot the computer and then reboot really quickly. The system started to shutdown as normal, showed the white ubuntu logo, but then the screen went black for approximately 20 seconds before actually closing down. It seems to me as if it was waiting for the bootchart logging to stop before closing down. I checked the relevant bootchart - the png file was generated but was 0 bytes. I parsed the data manually and I've attached the bootchart. I don't know whether this minor issue requires it's own bug report.

[HannesB (hannesb)]

ureadahead also fixes the problem for me:
45 instead of 70 seconds on an older laptop:)
even faster than the famous 9.04 (52 sec)now...
good work, thx!

In my bootchart there are still some times where disk utilization is high, but throughput is low, so there is still room for improvements, but those can wait until lucid:)

[Alan Goldblatt (alan-b-goldblatt)]

I actually switched to ureadahead several days ago -- can't remember how the idea came up -- so I don't have charts for right before and right after, but here's the best I've got.

Ureadahead a great improvement -- by stopwatch from 2:30 with s- down to 1:30 with u-

I too have much "disk utilization" without throughput or cpu use. Tried deleting 85-hdparm with no change in time.

Also, I tried commenting out the pre-stop script in bootchart.conf; Made the bootchart itself much shorter, but made no difference on the actual time from grub to desktop.

So, down to about 1:10 -- not bad, but wasn't the goal in Karmic a 10 or 15 second boot?

Thanks, Scott, for all your work!

-Alan

hmmm, it's not leting me upload my attachments -- will try separately.

[Alan Goldblatt (alan-b-goldblatt)]

Oh, one more thing. There's a point early in the boot when it says "Starting AppArmor Profiles". It gets stuck on this for more than 30 seconds before it continues displaying boot messages. Is it actually doing anything during this time?

[Alan Goldblatt (alan-b-goldblatt)]

When I try to upload my bootcharts I get the message "cannot upload empty file". Suggestions? They all open fine for me to examine.

[Farooq (farooqmian)]

This attachment contains bootchart graphs for sreadahead and after applying the patch, for ureadahead. Seems like the upgrade have given 5 seconds boost i.e. it was 70sec for sreadahead and is 65sec with ureadahead. But overall, it's still very very slow as compared with Jaunty which used to boot in 20sec.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 17:53 +0000, Ryan wrote:

> My before and after hover right around 131s tried remove on *pack, and
> did two more reboots. Here's the ureadahead --dump dump in case it is
> of any interest.
>
Actually your boot time is 55s (look at the point on the chart where CPU
and I/O activity ceases)

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-11-10 at 19:20 +0000, FriedChicken wrote:

> In case you need it...
> Everything in the list has 0 blocks.
>
What kind of filesystem are you using? Are you using wubi or anything?

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-11-11 at 06:25 +0000, Farooq wrote:

> This attachment contains bootchart graphs for sreadahead and after
> applying the patch, for ureadahead. Seems like the upgrade have given 5
> seconds boost i.e. it was 70sec for sreadahead and is 65sec with
> ureadahead. But overall, it's still very very slow as compared with
> Jaunty which used to boot in 20sec.
>
Your boot time is 45s, not 65s, with ureadahead.

You didn't supply a jaunty bootchart, so I don't believe your 20s claim.
Are you reading the "Time:" bit rather than looking at the chart itself?

Scott
--
Scott James Remnant
<email address hidden>

[smooth (hsavio)]

Rebooted a couple of times and commented /etc/init/bootchart.conf and timed the boot time with stop watch.
It dropped to 29 secs....

Nice work Scott.

Thanks.

[FriedChicken (domlyons)]

>
> > In case you need it...
> > Everything in the list has 0 blocks.
> >
> What kind of filesystem are you using? Are you using wubi or anything?
>

XFS on / and ext3 on /boot. No, it's a native installation.

[Jamie Strandboge (jdstrand)]

Upgrading to the sreadahead in karmic-proposed (in main) pulls in ureadahead from from universe.

[phil (pjonasch)]

Yes, it works much better. Thank you Scott!
But I'm still getting more than duble the boot time I had in jaunty if I'm not mistaken (?).
Attached are bootcharts of the different kernel-versions.
What is my problem? (said one shrink to the other..)

[Martin Pitt (pitti)]

Jamie Strandboge [2009-11-11 13:54 -0000]:
> Upgrading to the sreadahead in karmic-proposed (in main) pulls in
> ureadahead from from universe.

Fixed some hour ago, promoted to main now.

[phil (pjonasch)]

I attached one last bootchart,
am now on autologin again.
The bootchart says 1,34, but my handheld chronometer said 1,06 from Grub to end of hdd activity.
I find this almost acceptable.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-11-11 at 13:58 +0000, phil wrote:

> Yes, it works much better. Thank you Scott!
> But I'm still getting more than duble the boot time I had in jaunty if I'm not mistaken (?).
> Attached are bootcharts of the different kernel-versions.
> What is my problem? (said one shrink to the other..)
>
No problem, bootchart just runs for longer in karmic ;-)

In jaunty, this only covered the core boot sequence - and didn't even
include the time for the login manager to show up. In your
sylvester-jaunty-20091028-1.png chart, Xorg is still initialising where
the bootchart cuts off on the RHS @ 55s.

Comparing that to your sylvester-karmic-20091111-4.png, Xorg finishes
initialising around 45s (10s faster) - the bootchart simply then carries
on to include your desktop login and the first 30-45s of your desktop
usage.

Scott
--
Scott James Remnant
<email address hidden>

[phil (pjonasch)]

I see... so the problem has been (among others) my understanding of the bootcharts all along. Just as I suspected..
So thanks again Mr. Remnant, personally, I consider this problem solved. Startup times around a minute are cool for me.
This was fun though. Let's have this same dance all over again next time with Lucid! ;)

[Tyson Williams (bender2k14)]

>I consider this problem solved. Startup times around a minute are cool for me.

I don't know what system you are using, but the actual boot time is less important that the difference or ratio between the current boot time and past boot times. My SSD netbook only required 20-30 seconds to boot with Jaunty (although I have no bootchart to prove it), but Karmic is takings 60+ seconds. In my case, "startup times around a minute are 'not' cool for me."

[Johan Kiviniemi (ion)]

I guess verification-needed means you actually want “me too!” replies, so here goes.

I’ve been running the kernel and ureadahead from the ubuntu-boot PPA and afterwards from karmic-proposed, including the very latest packages it currently has. It has worked for me all the time without problems.

[phil (pjonasch)]

"startup times around a minute are 'not' cool for me."
I'm sorry if my level of satisfaction offends you. I did not mean to end the discussion (couldn't do that if I tried anyways) and I'm sure there is still a lot of work to be done. But right now I won't be able to contribute anything positive to your problem or the process as a whole (since I'm only a clueless user) and so I'm tipping my hat to the very capable Canonical staff and bid you good day until we meet again in more Lucid times.

[Omer Akram (om26er)]

40secs acer aspire one ssd version

[Tyson Williams (bender2k14)]

>40secs acer aspire one ssd version

I also have an AAO, but my boot time is 60+ seconds. WIll you post a bootchart?

[Martin Pitt (pitti)]

Johan Kiviniemi [2009-11-11 15:49 -0000]:
> I’ve been running the kernel and ureadahead from the ubuntu-boot PPA and
> afterwards from karmic-proposed, including the very latest packages it
> currently has. It has worked for me all the time without problems.

 +1 on my system, for contributing to verification feedback

[Bdopo (safelydeliver-online)]

I am also having increased boot times after upgrading Karmic. It is on its own partition, and I'm using a HDD. I havent run this command yet: sudo add-apt-repository ppa:ubuntu-boot/ppa
  sudo apt-get update
  sudo apt-get dist-upgrade

Sometimes on boot, I get the new splash logo, and other times its a text based boot. It seems like the boot process always gets into trouble when its time to load my partitions. Upon first upgrading, it used to get stuck on loading the different partitions but then after trying to boot into recovery mode and failing with a garbled blue screen and several reboots later, I was able to boot into Karmic. As of now, boot is really slow and when I randomly get the text based start up, it seems like it progresses a lot slower than Jaunty where various messaged splashed on the screen rather quickly before boot.

[Steve Langasek (vorlon)]

Hi Scott,

On Tue, Nov 10, 2009 at 05:38:14PM -0000, Scott James Remnant wrote:
> hdparm sync of death. I should file a bug about that ;)
> - delete /lib/udev/rules.d/85-hdparm.rules

If we don't use the udev rule, what will set the initial power management
policy for the drive? We don't want to rely on /etc/init.d/acpi-support,
since for one thing that's not guaranteed to catch all drives after they've
been probed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-11-12 at 09:21 +0000, Steve Langasek wrote:

> On Tue, Nov 10, 2009 at 05:38:14PM -0000, Scott James Remnant wrote:
> > hdparm sync of death. I should file a bug about that ;)
> > - delete /lib/udev/rules.d/85-hdparm.rules
>
> If we don't use the udev rule, what will set the initial power management
> policy for the drive? We don't want to rely on /etc/init.d/acpi-support,
> since for one thing that's not guaranteed to catch all drives after they've
> been probed.
>
You know that this does nothing out of the box, right? Other than call
sync 32 times during boot

Scott
--
Scott James Remnant
<email address hidden>

[Bdopo (safelydeliver-online)]

Bootchart after installing the ureadhead from the boot ppa. 4 second difference.

[Huy V. Le (huyvieto)]

On an Aspire One ZG5 with the stock 8GB SSD.

Under UNR 9.04 it took less than 1 minutes to cold boot and have Firefox Loaded.

Now with UNR 9.10, it take close to 2 minutes just to cold boot to the desktop.

I did two changes to try to improve the perdormance, set the elevator=noop.
Modified in the fstab and put 0 instead of 1:

UUID=Xyz / ext4 errors=remount-ro 0 0

It didn't change much the boot time.

Attached bootchart, hope it help to find the issue.

[ScottHW (publicw)]

I've been experiencing significantly slower boot times since upgrading to Karmic. Too bad, as one of the main features I thought we were going to look forward to was faster booting.

In Hardy, I was booting in ~0:39
In Jaunty, I was booting in ~-0.26
In Karmic, I was booting in ~1.22

Upgraded to ureadahead, I am booting in ~1.19

(sorry, I also apparently don't know how to attach multiple files...)

[ScottHW (publicw)]

Here is a Jaunty bootchart

[ScottHW (publicw)]

Here is a Karmic bootchart (with sreadahead)

[ScottHW (publicw)]

And finally, Karmic with ueadahead.

I've tried to pick random representative bootcharts for each of the described versions.

[Tormod Volden (tormodvolden)]

Boot times from grub to gnome-panel loaded (and CPU drop), on a dual-core 3GHz Intel, 2GB RAM, Samsung SP2504C SATA-II drive (using autologin):
- jaunty: ~43s (but not so stock install any longer)
- karmic-updates: 28s
- karmic-proposed: 22s

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-11-12 at 22:28 +0000, Bdopo wrote:

> Bootchart after installing the ureadhead from the boot ppa. 4 second
> difference.
>
This is still profiling, make sure you have a /var/lib/ureadahead/*pack
file and reboot again :-)

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-11-13 at 08:35 +0000, ScottHW wrote:

> I've been experiencing significantly slower boot times since upgrading
> to Karmic. Too bad, as one of the main features I thought we were going
> to look forward to was faster booting.
>
> In Hardy, I was booting in ~0:39
> In Jaunty, I was booting in ~-0.26
> In Karmic, I was booting in ~1.22
>
> Upgraded to ureadahead, I am booting in ~1.19
>
Please open up your jaunty and karmic (ureadhead) bootcharts; that goes
for everyone else too ;-)

Now first, please ignore the "time:" bit at the top. That is *NOT* your
boot time, that is simply the number of seconds after boot that
bootchart exited (for whatever reason).

Reading jaunty, scroll down and look at the chart; look at what the last
thing happening before the chart is cut off: It's about 3/4 the way
down:

  [gdm ]
  [Xorg ]
        [sh]
    [xkbcomp]

So this chart is being cut off as soon as the X server is started, and
the other init scripts are finished.

Reading karmic, you'll notice that the chart is much wider and that the
CPU and I/O graphs of the last bit are empty. That's because bootchart
runs longer to capture _more_ of the boot.

Try and find the same gdm/Xorg pattern - it's not at the right hand side
of the graph is it? In fact it's almost exactly in the middle.

jaunty wasn't booting faster - the karmic bootchart just *also* includes
your desktop login as well (since we care about both)

Scott
--
Scott James Remnant
<email address hidden>

[Huy V. Le (huyvieto)]

Hi Scott,

When you say Jaunty wasn't booting faster, I'm not sure then what was faster in Jaunty.

See my previous post, How can we achieve the same performance, boot and load Firefox in less than 1 minutes.

I have attached some bootchart with/out elevator=noop.

Hope it can help to improve performance.

Regards,

Huy

[Tormod Volden (tormodvolden)]

On my moderately equipped laptop (1.6 GHz Pentium M, 1GB RAM, Samsung HM160HC P-ATA drive, ureadahead is not better then sreadahead when it comes to get my desktop ready to use. I think the time where disk and CPU has calmed down is the most telling figure for practical purposes. This time is pretty much the same. ureadahead seems to read a lot faster, but it blocks all other processes while it is running, afterwards these processes crave for CPU without using the HD much. With sreadahead both disk and CPU activity is evened out through the whole boot.

[Bdopo (safelydeliver-online)]

Hi Scott,
  Thanks for your reply. I checked and I do have a /var/lib/ureadahead/*pack
and I've rebooted several times with no great speed difference. Visibly, I can see the sequence of texts that flash on my screen go faster (almost like jaunty) with this new ppa installed. Attached is a bootchart of my most recent boot?field.comment=Hi Scott,
  Thanks for your reply. I checked and I do have a /var/lib/ureadahead/*pack
and I've rebooted several times with no great speed difference. Visibly, I can see the sequence of texts that flash on my screen go faster (almost like jaunty) with this new ppa installed. Attached is a bootchart of my most recent boot?field.comment=Hi Scott,
  Thanks for your reply. I checked and I do have a /var/lib/ureadahead/*pack
and I've rebooted several times with no great speed difference. Visibly, I can see the sequence of texts that flash on my screen go faster (almost like jaunty) with this new ppa installed. Attached is a bootchart of my most recent boot

[Alan Goldblatt (alan-b-goldblatt)]

@Tormod -- your setup seems to be quite different for those two bootcharts. The one for s- is loading a lot fewer services (no compiz, no panel, etc.). I think if you try s- vs. u- with otherwise identical setups you'll find u- to be much faster than s-. (Also, your boots are pretty nice and quick either way.... I wish mine would boot so fast.)

-Alan

[ErikBerglund (a-launchpad-snap-345-blog-no)]

In Jaunty SSHD and SMBD started in less than 20 seconds, now they both take over 45 seconds.

I've tried the following:
1. Upgrading to GRUB 2.
2. Disabling unused services.
3. Changing CONCURRENCY=none to CONCURRENCY=startpar in /etc/init.d/rc

Nothing has helped.
I'm booting from a 500 GB SATAII 7200rpm disk with ext4.

?field.comment=In Jaunty SSHD and SMBD started in less than 20 seconds, now they both take over 45 seconds.

I've tried the following:
1. Upgrading to GRUB 2.
2. Disabling unused services.
3. Changing CONCURRENCY=none to CONCURRENCY=startpar in /etc/init.d/rc

Nothing has helped.
I'm booting from a 500 GB SATAII 7200rpm disk with ext4.

[ErikBerglund (a-launchpad-snap-345-blog-no)]

Installed the PPA, boot is now noticably faster. SSHD and SMBD start in less than 25 seconds.

Still not as fast as Jaunty, though.

[Brian Pitts (bpitts)]

Compared to my previous attachment, this one is much better.

[Eric Appleman (erappleman)]

My system is similar to Tormo's

1.6 GHz Core Duo, 2 GB RAM, 54000 RPM 160 GB SATA HDD

[Eric Appleman (erappleman)]

btw, i have 4 partitions (in order). /root, /home, swap, windows.

[Shaji N V (nvshaji)]

Scot,

I have couple of issues -

1. sreadahead is required by metapackages ubuntu-desktop and ubuntu-netbook-remix, which get removed when I replace sreadahead with ureadahead. Minor problem - but it would be cleaner if package dependencies are sorted out.
2. First time when I installed ureadahead along with a new kernel and rebooted, it did recompile dkms modules ( have 3 modules) upon next boot. This process made next boot slower, and ureadahead profile to collect 5500 files
          strings /var/lib/ureadahead/pack | wc -l
Now i removed pack file, reinstalled ureadahead and this time pack has only 2400 files.

Probably profiling needs to be done on multiple boots and take the common files across to optimize this.

[FriedChicken (domlyons)]

@Scott:

> > In case you need it...
> > Everything in the list has 0 blocks.
> >
> What kind of filesystem are you using? Are you using wubi or anything?
>
>
>XFS on / and ext3 on /boot. No, it's a native installation.
(post #69)

I've trid this on two more systems, two of them with XFS (and ext3/4 for /boot) and one with JFS:

- XFS (1) and JFS: As above every entry has "0 blocks". ureadahead is doing something on booting but overall boot takes longer or is just as fast as on profling.

- XFS (2): the same and "cat /var/log/syslog | grep ureadahead" gives:
  ... init: ureadahead-other main process (915) terminated with status 4
(appears on every boot)
Also there's a delay of 5 s (sleep just after usplash and resume). I will attach the bootchart of this system.

I guess the last one is a seperate bug but what about the "0 blocks"-problem?

[FriedChicken (domlyons)]

I don't know why but profiling seems to be done several times... This chart is one of them.

[Robin S. Parriath (robinparriath)]

Doesn't seem to make much of a difference on my machine. I get the same 1 min 25-30 secs on stopwatch.

Attached are the bootcharts.

[Scott James Remnant (Canonical) (canonical-scott)]

ureadahead has now replaced sreadahead in both karmic (via -updates) and lucid

[Martin Pitt (pitti)]

It's only in -proposed. However, it matured enough now, and we got enough feedback to demonstrate that it is a huge improvement.

Copying over now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ureadahead - 0.90.3-2

---------------
ureadahead (0.90.3-2) karmic-proposed; urgency=low

  * über-readahead is a replacement for sreadahead that should
    significantly improve boot performance on rotational hard drives,
    especially those that had regressed in performance from jaunty to
    karmic.

    It does this by pre-loading such things as ext2/3/4 inodes and opening
    files in as logical order as possible before loading all blocks in one
    pass across the disk.

    On SSD, this behaves much as sreadahead used to, replacing that package
    with slightly improved tracing code.

    This requires the kernel package also found in karmic-proposed.

    LP: #432089.
 -- Scott James Remnant <email address hidden> Mon, 09 Nov 2009 18:38:51 +0000

[Christian Loos (cloos)]

After upgrade from jaunty to karmic my boot time was rising from 1 minute to 10 minutes.
Even after I installed ureadahead and linux-image from proposed, boot time is also 10 minutes.
So from my point of view this bug isn't fixed. Attached is my dmesg.
If you need further information just contact me.

[Steve Langasek (vorlon)]

Even pessimal handling by ureadahead wouldn't account for a 10 minute boot time. You appear to have an unrelated issue; please file a separate bug report.

[ 5.120214] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001106664555572b]
[ 556.653356] PM: Starting manual resume from disk

The gap in time in the logs happens right after initializing your firewire interface; you probably need to file a bug against the 'linux' package.

[Steve Langasek (vorlon)]

Also, this could be due to a buggy, non-standard script in your initramfs, so please include a full listing of all the scripts under /usr/share/initramfs-tools/scripts/ (ls -lR /usr/share/initramfs-tools/scripts/) in your bug report.

[Omegamormegil (omegamormegil)]

Christian,

Sorry you are still having trouble. Lots of people have reported that this
solution has made substantial improvements to their boot time, effectively
fixing this bug for all of them. If you are still experiencing a slow boot
time, it would be best to open a new bug report because you must have a
different issue.

Feel free to post a link to your new report here, so other people having the
same problem as you might have an easier time finding your report.

On Tue, Dec 1, 2009 at 3:10 PM, Christian Loos <email address hidden>wrote:

> After upgrade from jaunty to karmic my boot time was rising from 1 minute
> to 10 minutes.
> Even after I installed ureadahead and linux-image from proposed, boot time
> is also 10 minutes.
> So from my point of view this bug isn't fixed. Attached is my dmesg.
> If you need further information just contact me.
>
> ** Attachment added: "dmesg-2009-12-01.log"
> http://launchpadlibrarian.net/36308039/dmesg-2009-12-01.log
>
> ** Changed in: ureadahead (Ubuntu Karmic)
> Status: Fix Released => Fix Committed
>
> --
> performs poorly on slow HDD
> https://bugs.launchpad.net/bugs/432089
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “sreadahead” package in Ubuntu: Won't Fix
> Status in “ureadahead” package in Ubuntu: Fix Released
> Status in “sreadahead” source package in Karmic: Fix Released
> Status in “ureadahead” source package in Karmic: Fix Committed
>
> Bug description:
> Binary package hint: sreadahead
>
> This is a tracking bug to improve performance on HDD disks, especially the
> really slow ones where sreadahead and the kernel have a deathmatch
>

[Jamie Lawler (jamie-lawler)]

You could also try disabling firewire in your BIOS and see if that solves the problem.

[Christian Loos (cloos)]

Steve, attached the initramfs scripts.

After the upgrade from jaunty to karmic and the 10 minutes boot time I tried different things:
- fresh karmic installation
- blacklisting the ieee1394 and ohci1394 modules
- disabling swap partition after reading bug 479611 that have the same dmesg entry after the delay like my one

all without success.

So I thought that this bug will tracking all related boot delays after upgrade from jaunty to karmic.

But ok I will open a new bug and hope someone can fix my problem.

[Christian Loos (cloos)]

Just created bug 491045.

[Tim (tzakharov)]

I saw this come through Karmic's updates. I almost started the install then noticed in the changelog:
"This requires the kernel package also found in karmic-proposed."

Since I don't have karmic-proposed enabled, does that mean installing this update could break my system?

[Martin Pitt (pitti)]

Tim [2009-12-02 0:52 -0000]:
> Since I don't have karmic-proposed enabled, does that mean installing
> this update could break my system?

No, the kernel is already in -updates now, and even if you don't run
that the worst thing that can happen that you get no readahead at all,
and thus no speedup.

[Dan Andreșan (danyer)]

Nice, ureadahead shave 50% of my boot time.

Now, sreadahead is left as a "transitional package" which can be removed.

When I want to remove it (I like things as clean as possible) it "helpfully" offer to remove ubuntu-desktop too.

Could you remove the dependency? Thanks.