[linux-mm-cc] Default size of Compcache (0.5.3) in Ubuntu Karmic.

[John McCabe-Dansted]

The size of the Compcache in Ubuntu Karmic defaults to the compcache
standard of 25% of ram. This is not enough to allow a livecd install
with 128MB of ram. By increasing compcache to 100% of RAM, we *can* do
a livecd install. I was thinking of recommending that they set the
size of compcache to be 100% of RAM using e.g.
  COMPCACHE_SIZE_KB=`grep MemTotal: /proc/meminfo  | sed s/[^0-9]//g`
  ...
  insmod compcache.ko compcache_size_kbytes=$COMPCACHE_SIZE_KB

or
  insmod compcache.ko memlimit_kb=$COMPCACHE_SIZE_KB
when they update to compcache 0.6

I understand that the reason the default compcache is 25% of memory is because:
  - There are performance regressions over disk based swap when over
~50% is used
  - Concerns that larger compcache may lead to faster battery drain on
embedded drivers.

However it appears that these concerns do not apply to the Live CD
 - where it is likely there is no disk based swap... in which case a
larger compcache will lead to less memory used and better performance.
 - People probably aren't going to be installing Ubuntu on battery power.

It seems to me that 100% compcache is reasonably conservative, as I
have found 140% and over can be useful to minimize physical memory
requirements in some tests.

Also, I understand that in since the 0.5.x does not flood the vmalloc
area, in 0.5.3 we no do not need to limit the size of compcache. I.e.
there are no known issues with having a 3GB compcache on x86, or truly
vast compcache sizes on 64bit architectures?

Another possibility would be to use a formula like max(130MB,
MEM_SIZE/2). This would ensure that if we could install using the
livecd on 128MB machines while not having regressions relating to
people enabling both compcache and disk swap; then wondering why their
machine slows to a crawl when they fill memory with /dev/rand.  Does
this sound like a better option?

A final question, in compcache-0.6.x, will it be possible for the
livecd to leave a decent sized ramzswap0 swapped on, and add/remove
the physical swap backing stores with rzcontrol?

I imagine that we could have a wrapper rzswapon rzswapoff. A simple
implementation could simply create a new ramzswap device and move over
all the swap to the new rz device each time a physical backing store
is added or removed. With support from the kernel module we could
perhaps have a pool of ramzswap devices and a pool of physical stores,
so e.g. a rzswap on would result in an additional ramzswap device
being added to increase the amount of data the kernel can swap out the
to compcache module, and the backing store being added to a pool
which both of the ramzswap devices can use when they decide that it
would be optimal to move a page out to disk.

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