Arch Linux User Repository

https://www.archlinux.org/todo/ Remove old initscipts rc.d files The time since initscipts became unsupported is sufficient that everyone should have transitioned and these files should be removed. Leaving them in packages appears to be causing some confusion among our users.

It does not work in the Raspberry Pi because in the script zramctrl awk counts the lines containing the word 'processor' in /proc/cpuinfo but the for the Pi this file has a different format than in the x86 systems. The easiest solution is to do an ignore case comparison something like: FILENAME == "/proc/cpuinfo" && ($1 == "processor" || $1 == "Processor") { But I don't know what would happen if at some point we have multicore ARMs. For a more robust solution I'd would inspect /sys/devices/system/cpu/cpu[0-9]* Probably the safest is to rely on the current method and only if it fails use the new approach. See in pastebin http://pastebin.com/2ydYbwU5

It does proclaim to have the same amount of swap space as there is RAM on my desktop (I never see the swap utilized), however it is not reserving physical memory unless paging is occurring. Since the swap is compressed, this should not equal all of the physical memory- however it will allocate physical memory of what (if any) is available when the swap is called. So if you only have .5 ~ 2 gigs of RAM being used up anyway, you basically run out of available memory and paging which will either crash or throw an application error from a lack of available memory and page space.

felixonmars: I wan't talking about that, I was talking about hitting the limit on the zram devices. Since they are in memory anyway, they are not true swap devices; suppose you swapped 2 GB of pages to a 2 GB swap device that is on 2 GB of physical memory. If the pages swapeed to zram are not easily compressible, it would mean that most of your physical memory is tied up in swap. I imagine this would trigger some pretty nasty out of memory situations. I'm not an expert on these matters either, but it seems dangerous to me to make that situation possible unless there's reason to believe that the scenario I described should never happen.

@loonyphoenix Last time I got a problem in compcache(zram) was because of bigger compressed data (than original data) so the zram got crazy when running out of memory. Within my understanding, they already fixed it by adding an "if" to ignore compressing when compressed data got even bigger than the trunk it could fit in. Yes this would still keep some memory chunk got bigger than they were, but prevent any fault that related to this from happening. Please do correct me if I got the upstream idea wrong, as I am not at all familiar with this, either: )

Hey, I've got a question. Isn't it dangerous to set the size of the swap to be equal to the physical memory size? What if you fill it with poorly compressible data (I see no reason why memory data should always be compressible) - then you've got practically no memory at all.

It seems pretty unstable. Tried this on my bootable thumb drive and it crashes a lot (no good for a btrfs compress USB stick). Desktop works fine but isn't really needed for that, I never need swap with the RAM I have nor do any applications I run use it. comcache isn't being maintained in AUR, other than code itself, functionality-wise I don't think there is much of a difference.

please add systemd support

as reported before, I even started to get kernel freezes now, so I had to stop using zramswap for a while. Is the problem still pervail? Btw, what is difference between zramswap vs comcache? Thanks,

Hello, Thanks for this script. I have two wishes. I would like you guys to point to the real upstream link, which is at the place of the dev of this kernel module: http://code.google.com/p/compcache The other wish I have would be for a configuration file to go along with this PKGBUILD : indeed, I would like to have a simple (kiss) way to choose how many block devices I want and what %age of my available ram I want it to be. I have been used to have the values recommended by the dev of the program : 1 block device and 25% of the available RAM, which fits my ordinary hardware (I have some starting from 512 MB ram to 4 GB ram, and several with 1 GB ram). The first time I have installed zramswap on this one machine which has a brand new install of Arch where systemd is at work, after I installed zramswap my machine hang with a kernel panic, which is the first time it happened since I started using zram, several years ago (when the package name was compcache). I have no idea how that must be set up to be able to work either with initscripts or with systemd, but I hope having a configuration file in both cases could be possible. Cheers, Mélodie