ubuntu-boot team mailing list archive

[Scott James Remnant <scott@xxxxxxxxxxxxx>]

==== Upstart ====

 * Fixed a bug with runlevel returning "N N" instead of "unknown"

 * Fixed a bug with runlevel not prefixing errors like "No such file or
   directory" with the utmp filename

 * Added missing Conflicts/Replaces/Provides for the upstart-job virtual
   package

 * Upstart 0.6.1 released and uploaded to Ubuntu

 * Fixed assertion when stopping a job during its starting event

 * Fixed fork watching to not break on exec() prior to first fork()

 * Upstart 0.6.2 released and uploaded to Ubuntu

==== D-Bus ====

 * Updated to 1.2.16 release

 * Some major gardening of the bugs list

 * Debugged issues with D-Bus not building with its test cases for Colin
   Walters, caused by our use of -Wl,--as-needed.  Need to contribute
   feedback to him (libdbus-convenience.la needs $(DBUS_TEST_LIBS) in
   LIBADD)

==== util-linux ====

 * Updated Debian and Ubuntu packages to 2.16 release.

 * Merged in changes from the stable/v2.15 branch back to master

 * Added the libuuid and uuidd package information from e2fsprogs

==== e2fsprogs ====

 * Updated to 1.41.8 release

 * Disabled building of libuuid and uuidd packages now they're built
   from util-linux

 * Sent patches upstream to disable building libblkid and libuuid by
   default, and alternate patches to make it optional in the packaging

 * Reverted Ted's system clock workaround in the package, sent the patch
   upstream

 * Some major gardening of the bugs list

==== module-init-tools ====

 * Updated to 3.10

 * Gardened the bugs list

==== Boot Performance ====

 * Received the HDD-based Dell Mini 10v (named "sam")

 * Installed jaunty release, then installed jaunty updates,
   karmic alpha 2 and karmic 20090717 onto it

 * For each release created bootcharts and kernel bootgraphs, before and
   after running "profile"

 * Results on the usual wiki page

==== sreadahead ====

 * Applied for VCS import of sreadahead SVN trunk

 * Reviewed the sreadahead issues/bugs and patches on SVN trunk that
   haven't been part of a release yet

 * Rebased Ubuntu package onto new import

 * Ported the original kernel ftrace() patch for the open() syscall to
   TRACE_EVENT, submitted to the kernel team

   * Not upstream because there's much better work to provide
     tracepoints for all syscalls, which would likely supersede this
     patch

 * Fixed sreadahead to stop it compiling with -march=native all the time

 * Re-applied fix for man page section

 * Fixed sreadahead to stop profiling on receiving the TERM signal
   instead of USR1

 * Re-applied and improved --no-fork patch

 * Investigatory work for using sreadahead on HDD-based machines

   * wrote a Python script to reorder the sreadahead pack based on
     on-disk location rather than time order, also adjusting fragments
     as necessary

   * tried various combinations of pack; single pack file for boot and
     desktop; separate pack files for rcS, rc2 and desktop; separate
     pack for file rcS, combined for rc2 and desktop; separate pack
     files for rcS and rc2 only; combined pack file for rcS and rc2 only

     ||'''Packs'''        ||'''Time'''||
     ||rcS + rc2 + desktop||40s       ||
     ||rcS, rc2, desktop  ||43s       ||
     ||rcS, rc2 + desktop ||41s       ||
     ||rcS, rc2           ||44s       ||
     ||rcS + rc2          ||47s       ||

     The theoretical benefit of splitting the packs up is that
     sreadahead's profiler works by tracking open() syscalls and then
     using mincore() to see how much of the file is in the page cache
     when it finishes profiling

     Thus more packs means more checks in the page cache, so in theory
     more things loaded in advance

     The numbers suggest that there's no benefit here; the pack dumps
     also suggest the same amount of date is read in any case.

     The reason for the slowness of the separate desktop pack is that
     there's no way to perform this synchronously, so it happened in
     parallel with the desktop load and thus lost performance benefit

   * tried various patches to sreadahead; to make it stay in the
     foreground while performing readahead; to perform the work in a
     single thread; increasing I/O priority while running.

     ||'''Variant'''           ||'''sam'''||'''wing-commander''||
     || bg, multi-thread, SSD  ||40s      ||68s                ||
     || bg, multi-thread, HDD  ||40s      ||66s                ||
     || bg, single-thread, HDD ||40s      ||68s                ||
     || fg, single-thread, SSD ||43s      ||72s                ||
     || fg, multi-thread, HDD  ||43s      ||63s                ||
     || fg, single-thread, HDD ||40s      ||60s                ||

     The times didn't vary much for sam, but this isn't surprising
     because it's a fresh install and the drive is in pretty much the
     right order

     When tested on my laptop, the times get wider spread and shows that
     the "HDD optimised" pack and sreadahead code do make a difference
     when combined, but each optimisation on its own can be a bad thing

     ie. foreground with an SSD pack isn't worth it (makes sense, it's
     in time order so you're really just wasting time)

     ie. background with an HDD pack isn't worth it (makes sense, it's
     in on disk order so doing other things will ruin the effort)

     (For comparison, times with original readahead were 41s and 68s,
      so sreadahead is at least as good - but with a *much* better
      profiler)

 * These results support switching to use sreadahead on HDD as well as
   SDD, with a special HDD mode that changes the pack order.

Scott
-- 
Scott James Remnant
scott@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part