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

Re: [nslu2-linux] Debian installer is too slow for NSLU2

Expand Messages
  • 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 1 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.