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 _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
