Loading ...
Sorry, an error occurred while loading the content.

Debian installer is too slow for NSLU2

Expand Messages
  • John Reiser
    Hi, On the fifth try over three days, I finally succeeded installing from debian-armel-5.0beta2.zip. Using only defaults (and the three required kernel
    Message 1 of 4 , Jul 3, 2008
    • 0 Attachment
      Hi,

      On the fifth try over three days, I finally succeeded installing from
      debian-armel-5.0beta2.zip. Using only defaults (and the three
      required kernel modules), the final successful run took 4.5 hours.
      This is too slow by a factor of 9 or 10.

      Environment: unmodified NSLU2 (133MHz CPU, 32MB RAM), 1.5Mbit DSL (160KB/s
      download speed from ftp.us.debian.org), 2GB USB2.0 flash memory device
      (6MB/s transfer rate), total 570MB installed in a single ext3 filesystem.

      Observation and experience with other systems suggests that debian-installer
      is poorly suited to the task of installing to system with low RAM and
      removable media. Instead, the system should be cross-installed to the
      removable media on a resource-rich system such as a x86 desktop PC. Then
      the media should be attached to the NSLU2, and the boot-up flash image
      should locate the proper filesystem (using dialogs), then re-flash the
      internal storage.

      The key observation: the activity LED on the USB2.0 flash memory device
      was flashing most of those 4.5 hours, even though the theoretical minimum
      write time was only about (570MB / 6MB/s) = 95 seconds. /proc/meminfo showed
      16MB of swapspace in use (SwapTotal - SwapFree), and ps showed a process
      with a virtual size of 45MB. The installer was thrashing in only 29MB
      of MemTotal. Although debian-installer recognized that it was in
      "Low memory mode", this fact did not alter _enough_ of the behavior.
      As soon as a single active process exceeds MemTotal, then thrashing is likely.
      Probably, the low-level memory allocator (malloc+free) and the application
      itself did not co-operate to keep the total arena below 29MB. free() must
      do "extra" work to avoid fragmentation, and malloc() should avoid scanning.
      Pretend that memory is a disk where access to a different page is expensive.

      Thrashing is likely when a long-running step accumulates results by using
      a linked list (such as: one item per package installed). Each new item in
      the list probably increases the fragmentation of RAM. Instead, accumulate
      incremental results in an array that is pre-allocated. In particular,
      explicitly force the storage for new character strings to be in known
      "super-" blocks of 50KB to 200KB or so, with space allocated sequentially
      using only one index, and freed as a whole super-block (if ever.)

      How can we encourage debian-installer to achieve cross-architecture installs?

      --
    • Kevin Price
      Hi! ... Too slow would be if it didn t work at all. It does work, so it is admittedly very slow, but not too slow. ... I personally don t think this is the
      Message 2 of 4 , Jul 3, 2008
      • 0 Attachment
        Hi!

        John Reiser schrieb:
        > [nslu2-linux] Debian installer is too slow for NSLU2

        Too slow would be if it didn't work at all. It does work, so it is
        admittedly very slow, but not too slow.

        > How can we encourage debian-installer to achieve cross-architecture installs?

        I personally don't think this is the right way to go, but I suggest
        posting your observations and ideas, which still might be very helpful,
        to the debian-arm mailing list:

        List-Subscribe:
        <mailto:debian-arm-request@...?subject=subscribe>

        jm2c.
        --
        Kevin
        http://www.kevin-price.de/
      • Martin Michlmayr
        ... This doesn t do exactly what you want, but you could simply unpack a Debian bar tall manually: http://www.cyrius.com/debian/nslu2/unpack.html ... You can
        Message 3 of 4 , Jul 3, 2008
        • 0 Attachment
          * John Reiser <vendor@...> [2008-07-03 08:19]:
          > Observation and experience with other systems suggests that debian-installer
          > is poorly suited to the task of installing to system with low RAM and
          > removable media. Instead, the system should be cross-installed to the
          > removable media on a resource-rich system such as a x86 desktop PC. Then
          > the media should be attached to the NSLU2, and the boot-up flash image
          > should locate the proper filesystem (using dialogs), then re-flash the
          > internal storage.

          This doesn't do exactly what you want, but you could simply unpack a
          Debian bar tall manually:
          http://www.cyrius.com/debian/nslu2/unpack.html

          > How can we encourage debian-installer to achieve cross-architecture installs?

          You can raise this issue on the debian-boot mailing list, but without
          actually putting in some effort yourself I doubt this is going to
          happen. An alternative would be to see whether the SLIND installer
          (where the installer itself runs on the host system) could be adapted
          to install Debian.
          --
          Martin Michlmayr
          http://www.cyrius.com/
        • Rod Whitby
          The cause of all that disk flashing and time wasted is selinux applying policies to all the files in the filesystem. BTW, no-one on nslu2-linux lists can help
          Message 4 of 4 , Jul 3, 2008
          • 0 Attachment
            The cause of all that disk flashing and time wasted is selinux applying policies to all the files in the filesystem.
            BTW, no-one on nslu2-linux lists can help change the debian installer - please report this to the debian-arm or debian-boot (I think) mailing list.
            -- Rod

            -----Original Message-----
            From: John Reiser <vendor@...>
            Date: Friday, Jul 4, 2008 12:49 am
            Subject: [nslu2-linux] Debian installer is too slow for NSLU2
            To: nslu2-linux@yahoogroups.comReply-To: nslu2-linux@yahoogroups.com

            Hi,
            >
            >On the fifth try over three days, I finally succeeded installing from debian-armel-5.0beta2.zip. Using only defaults (and the three
            >required kernel modules), the final successful run took 4.5 hours.
            >This is too slow by a factor of 9 or 10.
            >
            >Environment: unmodified NSLU2 (133MHz CPU, 32MB RAM), 1.5Mbit DSL (160KB/s download speed from ftp.us.debian.org), 2GB USB2.0 flash memory device
            >(6MB/s transfer rate), total 570MB installed in a single ext3 filesystem.
            >
            >Observation and experience with other systems suggests that debian-installer is poorly suited to the task of installing to system with low RAM and removable media. Instead, the system should be cross-installed to the removable media on a resource-rich system such as a x86 desktop PC. Then the media should be attached to the NSLU2, and the boot-up flash image should locate the proper filesystem (using dialogs), then re-flash the internal storage.
            >
            >The key observation: the activity LED on the USB2.0 flash memory device was flashing most of those 4.5 hours, even though the theoretical minimum write time was only about (570MB / 6MB/s) = 95 seconds. /proc/meminfo showed
            >16MB of swapspace in use (SwapTotal - SwapFree), and ps showed a process with a virtual size of 45MB. The installer was thrashing in only 29MB of MemTotal. Although debian-installer recognized that it was in
            >"Low memory mode", this fact did not alter _enough_ of the behavior.
            >As soon as a single active process exceeds MemTotal, then thrashing is likely. Probably, the low-level memory allocator (malloc+free) and the application itself did not co-operate to keep the total arena below 29MB. free() must do "extra" work to avoid fragmentation, and malloc() should avoid scanning. Pretend that memory is a disk where access to a different page is expensive.
            >
            >Thrashing is likely when a long-running step accumulates results by using a linked list (such as: one item per package installed). Each new item in the list probably increases the fragmentation of RAM. Instead, accumulate incremental results in an array that is pre-allocated. In particular, explicitly force the storage for new character strings to be in known
            >"super-" blocks of 50KB to 200KB or so, with space allocated sequentially using only one index, and freed as a whole super-block (if ever.)
            >
            >How can we encourage debian-installer to achieve cross-architecture installs?
            >
            >--
            >
            >
            >
            >------------------------------------
            >
            >Yahoo! Groups Links
            >
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.