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

[Nitin Gupta]

On 08/23/2009 09:04 PM, John McCabe-Dansted wrote:
> 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 think upgrade to compcache-0.6 is worth the effort. Some features:
  - Includes 'swap free notify' kernel patch: This eliminates any stale data
from (compressed) memory
  - Ability to create multiple ramzswap devices
  - Can have *file* as well as swap partition as backing swap
  - Works on ARM
  - Lots of small improvements all around

So, it would be great if someone can push this new compcache version for Ubuntu :)

> 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.
>

I have not experimented with various disksize values myself. AFAIK, you need
to actually experiment with target workload to see what works best. Yes, dynamic
ramzswap memlimit adjustment would be great to have but for now that seems quite
far away...


> 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?
>

Yes, with introduction of xvmalloc, there is no limit on how big compcache can be.

> 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?
>

Again, I think only with experimentation on target workload you can come
up with disksize/memlimit that works well.

> 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 didn't quite get it. What compcache-0.6 provides is multiple
/dev/ramzswap{1, 2, 3, ...} devices. For each of these devices you can
have separate physical (file/partition) device as backing swap.

In general, its better to have multiple ramzswap devices active instead
of a single giant ramzswap device since each of these has separate buffer,
memory pools etc. So, this will partly help with scalability and allow
adjusting compressed memory size at smaller granularity as you can swapon/off
individual devices without affecting others.

> 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.
>

This can certainly be done with compcache-0.6. However, note that number
of ramzswap devices is given by 'NUM_DEVICES' parameter for ramzswap module.
Once this module is loaded, no. of devices cannot be changed.
OTOH, creating large no. of these devices (say 16 or 32) is not an issue as
very minimal amount of memory is used for unused devices.

Thanks,
Nitin