[Techtalk] Thoughts on small boxes from Alan
hobbit at aloss.ukuu.org.uk
hobbit at aloss.ukuu.org.uk
Sat Jul 20 21:38:23 EST 2002
Since he sent it to me anyway, I thought I'd send it here. If it
gets forwarded elsewhere, then don't be confused by the headers.
This is not my work, it's Alan Cox's. Don't expect me to be able
to answer questions on it :)
Running A Linux Desktop On Low End Hardware
-------------------------------------------
One of the complaints that has been showing up recently has been that the
newer Linux kernel does not run on low-end PCs and that you need large
amounts of memory. Some of this was due to flaws in the early 2.4 virtual
memory (VM) layer of the kernel. Most of the problem in fact comes not
from Linux itself but from the applications running on top of it.
I set out to get a usable Linux desktop running on a 24Mb 486 machine. This
seems an eminently reasonable task given that the typical low-end machine for
people nowadays is a 32Mb Pentium-class system. The machine I picked for the
task was a Fujitsu Stylistic 1000. This machine has an 8bit display at
640x480 resolution, a fairly slow hard disk, 24Mb of RAM and an AMD 486DX33
processor. It has some other interesting quirks that need specific drivers
but those are not relevant to this discussion so will be ignored.
Why do we care?
---------------
Going prices on EBay UK for typical non-laptop machines:
PC (no monitor - typically you can add UKP10 for a monitor)
486DX2-66 32Mb UKP5-15
Pentium-90 32Mb UKP10-40
Pentium Pro 64Mb UKP75-120
Pentium II/233 64Mb UKP100+
The alternative is a new machine:
New machine UKP300+
New machine from general retailers UKP500+
Going prices on EBay UK for laptops (complete and working):
486DX2-33 24Mb UKP25-50
Pentium-133 32Mb UKP100-200
Pentium II/233 64Mb UKP300+
In the shops:
New machine UKP750+
If you simply need "a computer" there is a clear price benefit at the low
end. Similarly old 28.8 modems are extremely cheap, and in the worst case
14.4 (fine for mail, just about bearable for advert-filtered web browsing)
modems are basically free.
The Kernel
----------
The Red Hat-provided 2.4.7 kernel performed extremely badly on my test machine
as it had very old 2.4 VM code. The 2.4.9 errata kernel was much improved
but not perfect. Finally I installed 2.4.18pre7-ac3 on it, which has Rik
van Riel's rmap VM patches. This made the basic machine feel snappy, but
loading the GNOME desktop was unbearable.
Tuning Services
---------------
The next stage was to look through the installation and to use ps -aux to
find out what daemons were running and unnecessary. While the temptation
is to install a large amount of software, it isn't necessarily good
for performance (or security) to have it all running.
Using tksysv I turned off unneeded services like xinetd in order to free
up resources for other applications. From my fairly basic Red Hat install
this freed up several megabytes of RAM and swap - well worth doing on a
machine so tiny.
The GUI
-------
GNOME for (and because) of all of its neat features is never going to run
well on a machine this size; so I removed it from the machine. The next
question is how to find the best replacement. KDE has similar problems to
GNOME although they are often in different applications.
I installed XFce onto the system and after reconfiguring the
menus got a basic desktop that almost worked well. Starting up time from
typing "startx" was about 25 seconds. This is not instant but was acceptable.
I also replaced GDM with xdm to get a smaller graphical login. The gdm
or xdm daemon hangs around all the time, so smaller is better here.
With a desktop running it became possible to play with the applications.
Most of the XFce-provided programs worked well but there were continual
colour shortages on the 8-bit display. I rebuilt XFce to use imlib rather
than gdk-pixbuf as imlib supports small colour cubes and dithering. To
my surprise, this not only fixed the colour problems but took 5 seconds off
the startup time. Using imlib_config to cut down the imlib cache size
(it defaults to over 100K a program) I got startup time down to 15 seconds
and saw no appreciable performance drop.
Applications
------------
Getting the desktop into 24Mb is all well and good but it still doesn't solve
some of the remaining questions. Running mozilla on a 24Mb 486 is not one
of the most productive experiences. Running Evolution or Nautilus was clearly
out of the question.
In the end I settled on the following
rxvt - small text terminal application
dillo - small but nice web browser using gtk
(for people who are not purists about open source,
Opera is another obvious and excellent choice here)
sylpheed - a pure GTK-based Outlook-lookalike mail client.
ROX-Filer- GTK-based file manager with drag and drop.
ROX can provide a full desktop and you may want
to consider it as an alternative to Xfce too.
Not really being a wordprocessor person, I didn't worry too much about the
applications to use for that. AbiWord is a clear candidate here, while
OpenOffice for once is not.
Dillo required a small hack to change its default window size to be something
that actually fitted on the screen. It ignores --geometry which is an
unfortunate bug. At the moment Dillo only really scrapes the grade. I am
still looking for good alternatives that support SSL.
Sylpheed works exceptionally well and appears to offer pretty much
everything that is needed to provide a graphical mailer to an end-user.
ROX-Filer is very fast even on this machine. It lacks the funkier features
of Nautilus but everything in it Just Works. Integration is a little less
than ideal on the configuration side but integrating it into XFce is a current
work in progress and XFce will gain much from it.
Of course if you use the ROX desktop as the basic desktop then the
integration with the ROX panel and desktop management is excellent.
Resulting Usage
---------------
Fujitsu 486 with 24Mb of RAM running 8bit depth 640x480 SVGA X, and XFce.
An xterm is running to give the feel of having a minor application open.
The machine has pushed 9Mb of material into swap but is not swapping
data continually as it runs and is very usable.
The kernel on this machine has hotplug, and is a typical vendor configuration
kernel but using 2.4.18pre with rmap-11 patches.
total used free shared buffers cached
Mem: 22296 20228 2068 0 292 10596
-/+ buffers/cache: 9340 12956
Swap: 32796 9080 23716
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 1.3 1396 300 ? S Feb14 0:07 init [5]
root 2 0.0 0.0 0 0 ? SW Feb14 0:04 [keventd]
root 3 72.7 0.0 0 0 ? SW Feb14 2779:06 [kapm-idled]
root 4 0.0 0.0 0 0 ? SWN Feb14 0:00 [ksoftirqd_CPU0]
root 5 0.1 0.0 0 0 ? SW Feb14 5:47 [kswapd]
root 6 0.0 0.0 0 0 ? SW Feb14 0:00 [kreclaimd]
root 7 0.0 0.0 0 0 ? SW Feb14 0:04 [bdflush]
root 8 0.0 0.0 0 0 ? SW Feb14 0:01 [kupdated]
root 338 0.0 0.6 1400 140 ? S Feb14 0:06 syslogd -m 0
root 343 0.0 0.0 1392 20 ? S Feb14 0:02 klogd -2
root 459 0.0 0.5 1324 120 ? S Feb14 0:01 /usr/sbin/apmd -p
daemon 473 0.0 0.0 1372 4 ? S Feb14 0:00 /usr/sbin/atd
root 505 0.0 0.0 1368 4 ? S Feb14 0:00 gpm -t ps/2
root 517 0.0 0.4 1524 96 ? S Feb14 0:00 crond
root 580 0.0 0.0 1312 4 tty3 S Feb14 0:00 /sbin/mingetty tt
root 581 0.0 0.0 1312 4 tty4 S Feb14 0:00 /sbin/mingetty tt
root 582 0.0 0.0 1312 4 tty5 S Feb14 0:00 /sbin/mingetty tt
root 583 0.0 0.0 1312 4 tty6 S Feb14 0:00 /sbin/mingetty tt
root 1394 0.0 0.0 2560 4 ? S Feb14 0:45 /usr/sbin/sshd
xfs 8148 0.0 3.3 4444 752 ? S Feb14 0:25 xfs -droppriv -da
root 15167 0.1 4.6 2308 1028 tty2 S 00:39 0:00 login -- root
root 15169 0.0 1.3 1356 312 tty1 S 00:39 0:00 /sbin/mingetty tt
root 15323 0.0 0.4 1448 108 ? S 00:39 0:00 /sbin/cardmgr -f
root 15734 0.5 5.4 2324 1224 tty2 S 00:40 0:00 -bash
root 15820 1.2 4.2 3360 952 ? S 00:40 0:01 /usr/X11R6/bin/xd
root 15829 13.0 11.0 6884 2468 ? S 00:40 0:11 /etc/X11/X -auth
root 15830 1.2 8.8 4156 1964 ? S 00:40 0:01 -:0
root 15844 1.2 3.9 1948 872 ? S 00:41 0:00 /bin/bash /root/.
root 15887 9.0 7.4 3916 1664 ? S 00:41 0:06 xfwm
root 15894 17.6 16.9 5988 3776 ? S 00:41 0:10 /usr/bin/xfce 7 4
root 15895 2.0 10.2 5308 2276 ? S 00:41 0:01 xterm -title Term
root 15898 1.2 5.9 2328 1324 pts/0 S 00:41 0:00 bash
root 15951 0.0 3.6 2756 820 pts/0 R 00:42 0:00 ps -aux
Server Applications
-------------------
Not every 486 or pentium is being used for a desktop machine. It is possible
to get a long way with careful choice of server applications too.
For web-serving, replacing the standard Apache server (which uses a lot of
memory) with thttpd showed immediate large throughput improvements and
similar performance. Replacing it with boa showed even bigger gains in
memory but is less featured.
Sendmail clocks in at about 700K when running, but does have good resource
management functionality. If you receive little mail then you can run it
from inetd instead of its normal daemon mode. Other mailers such as exim
seem to come in at a similar size. When you are pulling mail off an ISP
POP-3 site you can avoid much of this overhead. Mail clients like Sylpheed
will talk directly, or you can exchange sendmail for ssmail which just
delivers mail to a fixed 'smarthost' and use a POP-3 mail-fetching client.
Conclusions
-----------
While the base libraries have increased in size and the kernel is a little
larger as a result of being more scalable, blaming the kernel for the increased
amounts of RAM is generally not the right thing to do. There has been
very significant growth in memory usage for the major desktops. In addition
the limits most distributions quote are due to their packaging tools and
smart front-end installers rather than being due to basic system limitations.
Hints
-----
Libraries
Try to pick applications that use the same libraries. Most of a
shared library resides in memory only once. If you use Qt-based
apps you probably want to use a Qt-based desktop on a small box.
The choices made in the article were designed to get all apps
using only glibc, Xlib and GTK+.
Kernel
For a tiny machine it is worth the effort of building a kernel that
has only the drivers you need built in and the rest either off or
modular. If you have to build kernels on your small machine, which is
quite common, then "off" will be best as it will drastically cut down
the compile time.
The new virtual memory work does really make a difference in the
small desktop environment. The rmap patches really show their worth
under this load. Andrea's -aa patches may do the same. I didn't
test those.
X11
Certain things really hurt X11 memory usage. Firstly come the things
you would expect - the larger the screen and the higher the colour
depth the more impact it has. In my case I had no choice but 8bit
anyway. Secondly background images are a real killer. On a low-end
box you will see this when you close windows and the background
slowly redraws as it is pulled back off disk. It is worth seriously
considering using plain colour backgrounds if the system is very
tight on resources.
Applications
Using the XFce desktop makes a 24Mb PC usable as a graphical desktop.
It provides a CDE-like user interface with basic file manager,
printing and configuration tools. It also provides menus for
application launching, window management and session handling.
Getting the base desktop down in size is a good goal for any smaller
machine. The desktop tends to be used all the time, while a single
large application will generally not be too unpleasant as it will
be the only application active when in use.
Look at the many 'second tier' applications. Gnumeric is not the only
Linux spreadsheet. One problem with the way Linux is covered is that
the big applications and major desktops are the ones that get noticed
There is a lot out there which is smaller, faster and less well known
- as Sylpheed clearly demonstrates.
Distributions
I set out to do this using Red Hat Linux, as this is my main Linux
of choice. In retrospect it may have been better to have started
from something more oriented to small systems. Red Hat rpm-4 uses
a lot of memory at times, and a 24Mb machine will not support the
standard Red Hat install. For an end user seeking to install on a
24-32Mb pentium class PC it might be more appropriate to choose
something like Debian. The Debian installer is not remotely user
friendly, but compared to hand-installing Red Hat is definitely
going to be easier.
Going Further
-------------
24Mb certainly isn't the limit. However it is possible to build a
nice desktop environment in 24Mb without major upheaval. The main
candidates to push further are
o Build a single video card 'kdrive' based X server
o Switch to diet-libc
Both of these go beyond the "download/install" stage and require
significant knowledge of the platform. This is appropriate for an
embedded platform but a significant challenge for an end user.
Technical Bits
-------------
Kernel
------
It may be tempting to recompile the kernel and look for ways to make it
smaller. On the whole this will have limited success as vendors ship
extremely modular kernels. It is however a win in some ways
- Most vendors compile in ramdisk support. You can skip this for
a few Kbytes. The vendors need it for boot initrds.
- Process accounting is generally not used on small systems. It's an
easy target to lose but alas not very big.
- Favour an i386 kernel over an i486 kernel; or, if you do not mind
tweaking the Makefiles, change arch/i386/Makefile to use the
options "-malign-functions=0 -malign-jumps=0 -malign-loops=0"
with your processor of choice. This trades a small performance hit
for a memory reduction. The 486 processor likes to jump and
call addresses aligned at 16 byte boundaries. Removing all this padding
will avoid some swapping which on a tiny box is an overall win.
- Turn off CONFIG_PCI_NAMES. This will make the old /proc/pci a lot
less pretty but not affect the user mode "lspci" tool. By removing
a whole chunk of PCI names from the kernel text we save space.
- If possible (ie, if you have no PCMCIA/Cardbus) say no to hotplug.
Hotplugging forces chunks of code to stay in kernel to handle dynamic
configuration that just does not happen on an old desktop PC.
This will also pull cardbus and pcmcia controller support out of
the kernel - where on Red Hat at least it is compiled into the
kernel itself rather than being modular.
- Particularly avoid SMP and support for >1Gb of memory. This should
be obvious for tiny machines but it has a big hit all across the code.
- Unless you are booting off a software RAID volume (which isn't as
crazy as it sounds if you are using a pair of very cheap geriatric
disks to save money) you can make CONFIG_MD (raid drivers) modular
even if you use them for non-root file systems
- For networking you need IPv4 if you are connected to the internet
and Unix domain sockets always. Pretty much everything else can
be modular or removed. You may want to enable netfilter if your
machine is directly exposed to the network, but the Socket filter
is used by almost no applications so it can go.
On Red Hat you need netlink/rtnetlink support for the supplied
initscripts.
- Try and turn off every IDE disk feature you don't need. Really you
need IDE disk support and little else. If the machine is PCI bus
you want IDE PCI support and IDE PCI DMA support. That will get
you reasonable performance. Pick support for the specific PCI chipset
you have (see what lspci says if you are not sure) to get UDMA33/66/100.
On a machine that is swapping you really want to get the best
disk throughput.
A small caution - if you have an RZ1000 or a CMD640 you must
ensure you say yes to the bugfix support for these chipsets or you
may experience data loss. If you aren't sure then play safe on these
two and say yes. It's harmless if you don't have them.
- With SCSI try to enable just the minimum you need to compile in
and the rest as modules or not at all. If you have the root filesystem
on a SCSI device you must compile in SCSI disk and support for your
scsi controller.
- Linux supports a lot of serial cards in various unusual forms: both
variants on the normal PC ports and totally different designs of
device. If you only have the standard 2 or 4 PC ports be sure
to turn off non-standard and extended serial support.
- In general framebuffers are "just say no". On a PC-class machine,
using the text mode support on the video card is faster for older
machines and saves you having things like font tables in RAM. If
your video card has no support you may have no choice but to include
the VESA frame buffer and to boot with frame buffer support enabled.
- When you are trying to chase problems, don't be afraid of the debug
options. Most cause a measurable CPU hit but not a memory one. The
exception is "Verbose BUG messages" which can add 70K bytes to
the kernel image itself. The SysRq key support adds little to memory
and nothing to CPU usage. It can be useful in all environments.
- Finally if your machine is old then you won't have any APIC or IOAPIC,
so turn that off. You also won't have ACPI so turn that off (100K
back). You may well have APM power management support. APM uses little
kernel memory so is worth enabling. Most Pentium era machines have
properly working APM facilities but in the 486 world life was a bit
rougher. You may find that you need to play with APM settings or turn
off APM on such systems.
Tuning Hardware
---------------
If you have old hardware you may have some scope for tuning it or acquiring
extra junk. On an old ISA bus 486-class machine the prize hardware is probably
some kind of bus mastering I/O controller. There is little choice in this
area and the "dream item" is an Adaptec 1542B, 1542CF or 1535, which
lets you use SCSI disks with bus master I/O. The killer network card is
the AMD PCnet/ISA or the earlier "lance" chipset it derives from. This
is found on a fair range of ISA cards including the NE2100. In general
network performance is not the bottleneck and the trusty old NE2000 clones
can be found and bought by the bucketload.
With PCI bus machines there tend to be more options. Older PCI bus systems
are fairly flaky with many high-performance PCI controllers. Most of them
predate the PCI 2.1 standard. You should also be aware that on many of
these boards there are a limited number of (often only 1!) bus mastering slots.
Most modern network and I/O cards are bus mastering. If you have few
bus mastering slots you may have to look for older devices such as PCI
NE2000 clones. PCI bus video makes a huge leap over ISA bus video for
X11 use. Thankfully there are almost no PCI bus mastering video cards.
If your machine supports DMA IDE you are in paradise. This makes a huge
difference to your machine performance and is something to look out for on
the feature list - particularly for Pentium class machines.
Disk Layout
-----------
There are a few things about disks and their usage that are worth mentioning
in the context of this article. Firstly it is useful to know that on many
newer disks the outside edge of the disk is generally faster than the inside.
This is because the disk actually has more sectors per track on the outside
than the inside, because the track is longer. The drives lie about their
actual geometry to the machine itself.
Secondly you want to put commonly-used things either together if on the
same disk, or on a separate disk (for IDE a separate controller). The kernel
swaps data to the swap partition, which should therefore be on a disk that
has reasonable performance but, more importantly, has the lowest CPU usage,
if you have a choice between bus mastering SCSI and non DMA mode IDE go
for the SCSI device as swap.
A large amount of what is in memory is read but never written by the
processor. To save swap space and time the kernel simply discards such
memory and re-reads it from its original location on disk. Thus having your
common applications and libraries on the better disk always helps.
MCA Bus
-------
If you see an IBM PS/2 machine at a sensible price - ie near free (often PS/2
machines go on a 'you collect it, or it's in the skip' basis) don't just
ignore it. The MCA bus machines have both advantages and disadvantages.
Firstly they are very non standard. If you can get MCA bus kit you will often
get it for free. My main MCA card collection was "5Kg of MCA bus cards". The
cards are also generally quite high performance. Try to pick a machine which
has the devices you need and has SCSI interfaces. The IBM SCSI controllers on
most PS/2 machines are extremely good, often with caches, and will outperform
any ISA and most 486/586 era PCI controllers. The IBM 8514 and later
graphics controllers for MCA bus are also way ahead of their time. XFree86
3.3 supports them well.
The disadvantages to think about are these. You will never be able to
rescue any of the MCA bus system for future use except the disks. In truth
the same is true of many 486 class systems, but perhaps not Pentiums. It's
hard to find RAM so make sure you have the RAM you need when you get the
machine. What cards are around also varies. In an area that believed
IBM, people will literally throw them at you if asked. Elsewhere you
may not be able to find another MCA bus system or card however much you
search.
You will also need a distribution that includes an MCA bus supporting kernel.
That primarily means Debian, who have kept up good MCA bus support. For the
commercial vendors MCA bus support is a little hard to justify as a business
win.
Links
-----
Red Hat Linux http://www.redhat.com/
Debian GNU/Linux http://www.debian.org/
XFce http://www.xfce.org/
Dillo http://dillo.sourceforge.net/
Rox-Filer http://rox.sourceforge.net/
Sylpheed http://sylpheed.good-day.net/
AbiWord http://www.abisource.com/
thttpd http://www.acme.com/software/thttpd/
Boa http://www.boa.org/
ssmail (where _does_ this live?)
More information about the Techtalk
mailing list