This is an ebuild for compcache, see http://code.google.com/p/compcache/.
Created attachment 176741 [details] /var/repos/local/sys-kernel/compcache/compcache-0.5_pre1.ebuild Ebuild for compcache 0.5pre
Created attachment 176742 [details] /var/repos/local/sys-kernel/compcache/files/compcache-confd conf.d file
Created attachment 176744 [details] /var/repos/local/sys-kernel/compcache/files/compcache-initd Init script
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manor. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 176912 [details, diff] Patch for above build to fix output directory The Makefiles from the tarball have hardcoded the kernel output directory. This breaks for users employing KBUILD_OUTPUT to compile the kernel in a different directory. So the Makefiles need to be patched with KV_OUT_DIR as the output directory. The attached patch to the ebuild does this. BTW: Perhaps sys-fs is a better category than sys-kernel?
(In reply to comment #5) > BTW: Perhaps sys-fs is a better category than sys-kernel? sys-kernel somehow doesn't fit but sys-fs is IMHO even worse (unless you consider swap space a file system. Maybe sys-block?
Created attachment 177319 [details] More reliable compcache-initd On my machine 1 second is usually not enough until /dev/ramzswap0 appears. So I patched the compcache-initd script to wait until it is up (with some timeout to avoid an endless loop in case of problems). Since the patch is longer than the script, I attach the rewritten script.
Instead of using an init script, perhaps using a udev rule would be more elegant? That way, there's no sleeping/waiting, and the script is incredibly simple: KERNEL=="ramzswap0", ACTION=="add", \\ RUN+="/sbin/swapon -p 100 /dev/ramzswap0 2>/dev/null" See https://wiki.ubuntu.com/Compcache for some more ideas
Created attachment 192654 [details] updated ebuild for compcache 0.5.3 The module name changed to ramzswap. This ebuild reflects that change.
Created attachment 200151 [details] sys-block/compcache-0.5.3.ebuild clean up. I think that it should be in sys-block or sys-apps category.
Created attachment 200153 [details] sys-block/compcache-0.6_pre2.ebuild
It doesn't compile with my linux kernel 2.6.32-rc6, /ramzswap.c:1284: error: implicit declaration of function ‘blk_queue_hardsect_size’ Renaming the ebuild to simply compcache-0.6.ebuild (which I think is newer) also doesn't work with: /ramzswap.c:926: error: implicit declaration of function ‘bio_discard’ /ramzswap.c:1027: error: implicit declaration of function ‘blk_queue_set_discard’
The latest mercurial source code upstream works with the new kernels, so I guess we should just wait till they make a point release of it. (0.6.1 will no longer create an xvmalloc module, so the ebuild needs to be adjusted for that ... and the compiled rzscontrol binary should be used in the init.d scripts to create the space.)
Created attachment 213623 [details] sys-block/compcache-0.6.ebuild version bump, linux 2.6.32+ has ramzswap module inside staging drivers section, so this ebuild doesn't compile/install the kernel module.
Created attachment 213624 [details] sys-block/compcache/files/init.d-compcache init.d/compcache runlevel script
Created attachment 213627 [details] sys-block/compcache/files/conf.d-compcache conf.d/compcache settings file.
forgot th mention, my compcache-0.6.ebuild is confirmed to cross-compile fine - ie. you can do a `emerge-armv7a-softfloat-linux-gnueabi compcache` for beagleboard, etc.
I think bug #299664 is a duplicate of this bug.
Created attachment 221141 [details] sys-block/compcache-0.6.2.ebuild
Building the module is still required as per compcache documentation wrt kernel 2.6.33, also - I wonder if there's a way to check if the patch provided was applied to the kernel to compile accordingly
*** Bug 299664 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > Building the module is still required as per compcache documentation wrt kernel > 2.6.33, also - I wonder if there's a way to check if the patch provided was > applied to the kernel to compile accordingly > As for gentoo-sources-2.6.33-r1, no patch seems to be required. The ramzswap.ko module builds fine, and the rzscontrol from this ebuild works like a charm. One thing, though: Could an option be added to /etc/conf.d/compcache to set a priority for the ramz swap devices? (swapon -p option)
(In reply to comment #22) > As for gentoo-sources-2.6.33-r1, no patch seems to be required. The ramzswap.ko > module builds fine, and the rzscontrol from this ebuild works like a charm. Well, the ramzswap module isn't the latest code. It's missing the disksize_kb, memlimit_kb, and backing_swap module parameters. Maybe rzscontrol can control those things, but that's different from being able to specify them as module parameter. Looking at current v2.6.34-rc7 sources, it seems that the new module parameters are not there yet. Anyway, hopefully the in-kernel ramzswap module will catch up by 2.6.35 or so. When that happens we'll probably want a separate compcache-tools ebuild as in bug #299664.
It is posssible to do a version bump by copying this ebuild's directory into a local overlay and modifying the file names. The compcache-0.6.ebuild in sunrise is better written than the compcache-0.6.2.ebuild here, so doing that is probably a good idea.
Hi, I tried compcache-0.6.2.ebuild from comment #19, and it seems to work fine. There is an issue though. If ramzswap is statically compiled in, the ebuild can't control the number of devices, so it should check that the /dev/ramzswapN device node exists (by default the is only one).
Created attachment 239721 [details] add use flag for the swap_free_notify patch I've added a use flag that enables the optional (but recommended) swap_free_notify functionality. It also requires patching and recompiling the kernel (so I also added the patch to the dodoc) BTW, I think it is also important to add SWAPON_OPTS in the conf.d for setting the priority. It is important to set the same priority for all the devices when using multiple cpu core, but without passing -p to swapon, they will be created with different priorities.
Created attachment 239723 [details, diff] patch to the compache sources to enable the optional swa_free_notify feature filesdir patch used by the -r1 ebuild posted in the previous comment
compcache 0.6.2 doesn't work with kernel 2.6.35 anymore - for some additional information see http://code.google.com/p/compcache/issues/detail?id=68
Created attachment 260804 [details] compcache-0.7-r9999.ebuild This is a new ebuild to support trunk from mercurial This is needed now because it no longer uses any userspace helpers and we are just dealing with a kernel module. It also does more than swap! It can do your tmpfs mount too with a filesystem on top of it (e.g ext4) It requires the new init.d / conf.d attachments too and free_notify patch to be renamed. The initrd script still supports multiple swap disks and I added a little more sanity checks for the users who use monolithic kernels that have been patched. The userspace tools are gone, but if you one you need a different ebuild; http://bugs.gentoo.org/attachment.cgi?id=253479&action=view
Created attachment 260806 [details] new initd-compcache place in sys-block/compcache/files dir in your local portage overlay
Created attachment 260808 [details] new conf.d-compcache place in sys-block/compcache/files dir in your local portage overlay
Created attachment 260809 [details] new init.d-compcache fixes a missing $ in the script. hot of the press. put it in your files dir.
(In reply to comment #29) > Created an attachment (id=260804) [details] > compcache-0.7-r9999.ebuild Thanks, it builds/installs fine for me. I've noticed that the mainline linux-2.6.37 sources include swap_slot_free_notify support, so maybe the swap_free_notify USE flag isn't really needed, or could be enabled by default. Also, my kernel has CONFIG_ZRAM=m (drivers/staging/zram in mainline kernel), and the ebuild did not produce any warning about the redundant module. So, now I've got two zram modules: /lib/modules/2.6.37/compcache/zram.ko /lib/modules/2.6.37/kernel/drivers/staging/zram/zram.ko
(In reply to comment #33) > (In reply to comment #29) > > Created an attachment (id=260804) [details] [details] > > compcache-0.7-r9999.ebuild > > Thanks, it builds/installs fine for me. > > I've noticed that the mainline linux-2.6.37 sources include > swap_slot_free_notify support, so maybe the swap_free_notify USE flag isn't > really needed, or could be enabled by default. > > Also, my kernel has CONFIG_ZRAM=m (drivers/staging/zram in mainline kernel), > and the ebuild did not produce any warning about the redundant module. So, now > I've got two zram modules: > > /lib/modules/2.6.37/compcache/zram.ko > /lib/modules/2.6.37/kernel/drivers/staging/zram/zram.ko > the CONFIG_ZRAM=m (drivers/staging/zram) inside the kernel (2.6.35/2.6.36/2.6.37/9999) is some mysterious version of compcache and require some userspace tools i don't know where to find (or which hg version i should checkout from the repository). it's not 0.6.* nor 0.7.* (9999). 2.6.35 kernels doesn't have swap_notify_free(), the use flag is probably for that, i guess.
the control interface has changed a lot (from modprobe module params to ioctls to sysfs interface). and all of them are really different. module params take `modprobe compcache numdevices=8 disksize_kb=262144` like format of syntax ioctls requres some userspace tools to set the device size (but still take module params to set number of devices) the sysfs interface (latest) can just `echo 268435456 > /sys/block/zram0/disksize`, but still requres the numdevices module param.
(In reply to comment #34) > (2.6.35/2.6.36/2.6.37/9999) is some mysterious version of compcache and require > some userspace tools i don't know where to find (or which hg version i should > checkout from the repository). it's not 0.6.* nor 0.7.* (9999). The zramconfig utility works with 2.6.36, and there's an ebuild for it attached in bug 299664, comment #5 (note EHG_REVISION=146). The new sysfs interface is merged in 2.6.37, and documented in zram.txt: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/zram/zram.txt;hb=HEAD
I'm using the kernel module from the official tree (staging) in 2.6.37 with the pure sysfs interface and it works fine. I've modified the conf.d/init.d to use sysfs and no need for the zramconfig binary anymore (if anyone is interested it's here: https://github.com/asssaf/portage/tree/master/sys-block/zram ). Is there any advantage to using the hg source over the staging driver?
hmmm, so trying to make a 10MB zramdisk with just conf.d/modules and fstab fails right now because there is no way to specify disk size with modprobe? any other mechanism to react on modprobe zram with echo yaddayadda before we process fstab?
Bump.
I guess we can consider this superseded by zram-init: https://packages.gentoo.org/packages/sys-block/zram-init
