[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