casper neeeds to set compcache defaults to 50% on armel targets

[Oliver Grawert]

Binary package hint: casper

on some armel targets (i.e. omap) we need a compcache value of 50% instead of the default 25%

a patch like below needs to be added to debian/rules raise this value on armel builds:

--- casper-1.231/debian/rules 2010-04-09 04:01:09.000000000 +0000
+++ casper-1.231.orig/debian/rules 2010-04-11 08:32:09.414649350 +0000
@@ -1,6 +1,14 @@
 #! /usr/bin/make -f
+
+CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
+
 %:
  dh $@

 override_dh_installinit:
  dh_installinit -r --no-start -- start 89 0 6 .
+
+override_dh_auto_configure:
+ if [ $(CPU) = arm ];then\
+ sed -i 's/25%/50%/' $(CURDIR)/conf.d/compcache;\
+ fi

[Oliver Grawert (ogra)]

please grant a feature freeze exception for this change

[Oliver Grawert (ogra)]

note that the 50% make the live image work with 256MiB of RAM while with the 25% default compcache value we hit OOM, alternatively to the above it should be considered to bump the value altogether to 50% without any architectural workarounds which will then also help other architectures that run on 256MiB

[Loïc Minier (lool)]

Please patch the installed file rather than the source file, i.e. add the commands post-install. I'd name the rules var "DEB_HOST_ARCH_CPU" instead of CPU.

Adding a comment to rules to explain when this override can go away would be good.

Thanks!

[Loïc Minier (lool)]

If it's omap-specific, did you consider running this check at runtime? Perhaps it should be based on available memory instead of on subarch (AFAIK some OMAP boards will have 512M+ of RAM, so enough not to need the change.)

[Steve Langasek (vorlon)]

this looks like a bugfix, not a feature, so no FFe should be required.

[Oliver Grawert (ogra)]

@lool: there is already a runtime check that disables compcache usage completely in casper if more than 512MiB are available, the code is written in a way that requires the conf.d/ value to exist before update-initramfs is run inside livecd-rootfs, changing that behavior to a runtime one would result in massive code changes that will affect all live images which i'd like to avoid at this time of release ... though i'm more and more tending to actually set the value to a general 50% instead of using an arch specific hack at all since that will prevent OOM on x86 as well if you only have 256MiB

if nobody objects against that i'll just bump the genral default value in an upload tomorrow

[Loïc Minier (lool)]

I don't understand, why it would be "massive code changes", there's already a runtime check?

if [ "${BOOT}" = "casper" ]; then
    if [ "${TOTAL_RAM}" -gt 524288 ]; then
        exit 0
    fi
fi

modprobe -q --ignore-install ramzswap disksize_kb="$kbytes"

What I would personally find problematic in changing the runtime behavior is the current configuration interface with the COMPCACHE_SIZE variable which relies on the hardcoded 524288 TOTAL_RAM limit -- it's hard to generalize; we could introduce a COMPCACHE_LOWMEM_SIZE, and perhaps COMPACHE_RAM_LIMIT and LOWMEM_RAM_LIMIT vars to avoid hardcoding 512 MiB and 256 MiB. But I find that's a lot of changes to the config vars. I would also prefer if we'd simply change the compcache check from 512 MiB to 256 MiB, albeit one has to keep in mind that it's applied to all initrds, all images, so it will impact more environments...

[Oliver Grawert (ogra)]

casper (1.232) lucid; urgency=low

  * bump compcache size to 50% on live images for machines with less than
    512MiB. This makes sure we don't hit OOM errors on systems with only
    256MiB of RAM.

 -- Oliver Grawert <email address hidden> Mon, 12 Apr 2010 08:10:06 +0200

[Oliver Grawert (ogra)]

@lool: feel free to improve the handling if you feel the implementation we use since hardy doesnt suffice, but be aware that:
a) there are apps and tools in universe using the current implementation that need to be transitioned (in debian as well afaik)
b) the initrd compcache implementation has to be completely redone in maverick since compcache moved to mainline with 2.6.24 you need several userspace configuration tools to set it up and the setup handling changed completely.

in the light that we have to redo the design from scratch next release anyway and the current behavior is well established and tested since hardy i just bumped the value for now.

[Paul Larson (pwlars)]

Not sure if this is intended, but some machines that technically have 512M will be impacted by this, especially in cases where some of the RAM is stolen for video memory. For instance, my babbage 3 reports ~467M free after boot, and does get a compcache swap on the live image.

[Loïc Minier (lool)]

I complained the same on IRC, but was told that's the case since hardy included; in fact, even if you don't have any video memory sharing, machines with *exactly* 512 MiB will have compcache turned on. I personally expected that we'd have a lower cut value for compcache.