On Mon, Mar 3, 2008 at 10:57 PM, Colin Watson <[EMAIL PROTECTED]> 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 -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
