LiveCD patch for low-memory systems (192K)

[John McCabe-Dansted]

On Mon, Mar 3, 2008 at 10:57 PM, Colin Watson <cjwatson at ubuntu.com> wrote:
> [This should be on a development mailing list, surely?]

OK, moved to ubuntu-devel-discuss.

>  On Sat, Mar 01, 2008 at 04:15:22PM +0900, John McCabe-Dansted wrote:
>  > Hello, I have created a low-memory patch for the Ubuntu 7.10 LiveCD.
>  > This patch is based on compcache, see:
>  >   http://code.google.com/p/compcache/
>  > I have tested this on a 180MB VM and a 120MB VM with only-ubiquity. It
>  > worked in both cases.
>
>  Has this been brought to the attention of the Ubuntu kernel team? In
>  order to incorporate this, we'd need the necessary kernel modules to be
>  included in our kernel packages (linux-ubuntu-modules, I imagine), which
>  would definitely involve talking with them.

No, atm I am still working on testing and packaging compcache.

>  I'm assuming there are some downsides, on the "there ain't no such thing
>  as a free lunch" principle.

The downsides of compcache are similar to the downsides of physical
swap. In both cases swapping won't be as fast as having more physical
memory. Compared to physical swap:

PROS:
P1: Much faster
   (zero latency and decompression can be 25% as fast as memcpy)
P2: No need for swap partition.
P3: Less issues if hard disk is unreliable or corrupted
   (might be why we are booting from LiveCD).
P4: Places less load on harddisk

CONS:
C1: Requires Memory.
C2: Requires *Kernel* Memory (limited to ~1GB on i386)
C3: Places more load on CPU
C4: Less well tested than physical swap.
C5: Using compcache without physical swap risks triggering oom-killer
if user loads /dev/rand into memory.

C3 is less important than P4 on new desktops as DualCore single HDD
machines are now the norm. However in my testing of LiveCD in VMs I
have found that the mouse becomes jerky during install to HDD if
compcache is used. This may be because cpu is more important than HDD
on single core machines for having a responsive desktop.

C1 is irrelevant if no other form of swap is available, as 50% of
original size is still better than 100% of original size.
As to C2, I am capping compcache size to 175MB, so that less than
100MB of kernel memory will be used.

C5 isn't much of an issue for LiveCD. For any normal use, the
compression ratio will be almost exactly 50%. In practice the CD will
slow down and become unusable long before the oom killler would be run
anyway, and trying to advoid oom killer on pathological loads is
virtually impossible anyway. We just test the liveCD and see how
little physical memory we can have and still work reliably and
reasonably fast - exactly what what we would do without compcache. The
amount of physical memory required will almost surely be less than
without compcache.

> Can this be limited to systems with (say)
>  <384MB of memory?

We could do this easily, but in principle this would not gain us
anything. Compcache only allocates memory when the swap is used, so if
the kernel doesn't want swap then having Compcache enabled will make
no difference. If the kernel does want swap, it is probably best to
give the kernel swap of some form. Limiting to systems with <384MB
would help people with a large amount of memory avoid possible bugs,
but testing compcache on as many machines as possible and fixing any
bugs we find seems like a better solution.

Disabling or shrinking Compcache when we have access to physical swap
OTOH seems like a good idea. Letting compcache allocate 50% of memory
when HDD swap is available can degrade performace.  Ideally we'd keep
a dynamically sized compcache active at all times, as benchmarks have
shown that this either gives better performance than harddisk swap
alone, or has little effect. See
  https://wiki.ubuntu.com/CompressedMemory
for more information. Compcache-0.2 doesn't support dynamic resizing
effectively however.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia