Zram/Zswap is possible in LibreELEC/benefits?

  • Hi, guys!

    Yesterday I was thought if is possible to put an aplication to run only using swap memory.

    I don't finded this answer, but in this search I found out about zram and zswap. For what I understand zram is a way to compressed memory ram in this way help system with less memory. They say this will use more CPU, but maybe is something that worth it. I also read about zswap but don't know for sure what it do.

    Theres a way of enabler this things in LibreELEC?

    Will make a significant difference or will be a placebo?

    What will be best: zram or zswap?

    I searching about this because I use another things in background of my machine and sometimes I get a buffering in local videos reproducing in Kodi. I already use swap and I think this is because some pieces of Kodi are using swap memory in this time. But I'm kinda noob and don't know for sure. I know this is not a LibreELEC issue or Kodi.

    My hardware is a Raspberry Pi 3b.


    Supercalifragilisticexpialidocious! (inscribed in large friendly letters)

    My hardware is a Raspberry Pi 3b

  • edjalmo

    Changed the title of the thread from “Zram/Swap is possible in LibreELEC/benefits?” to “Zram/Zswap is possible in LibreELEC/benefits?”.
  • I would also like to know the answer to this question from the developers?

    Does LibreElec make use of this? I just discovered this technology today and I imagine there's at least 100MB (?) of data in memory which could just be compressed and left there?

    Any value in it?

  • It has very limited usage, typical LE uses less then 1gb RAM, so for every device with more then 1GB RAM it makes near to zero sense at all

    Devices with 1GB ram are also not really suited for it because typical 1gb devices are rather low end and if you enable zram you stress the cpu quite a lot.

  • I would (assume) only un-needed system files / drivers / modules which aren't frequently accessed would dropped into it.

    It's worked really well on my little Armbian PC. - none the less you guys know way more than I do!

  • and I imagine there's at least 100MB (?) of data in memory which could just be compressed and left there?

    What is this 100MB of data you are referring to - is it the squashfs image? This is already compressed so using zram to compress it again in RAM would not result in any significant benefit, and would in fact use more CPU to perform multiple rounds of uncompress/compress.

    LibreELEC is designed to perform well within the memory constraints of the target device, eg. 1GB RAM on RPi3, which (on everything other than RPi0/RPi1) still leaves sufficient spare RAM to run a few background applications/services, so zram/zswap should not be necessary.

    However if users choose to load the system to the point where all the available RAM is in use then that's not really a problem I think is worth solving with zram/zswap - the better solution is to partition your services on to dedicated/appropriate hardware so that LibreELEC as an HTPC client is running optimally (not having RAM/CPU intended for Kodi stolen by other background tasks) or continue using a single device but one with more physical RAM and/or faster CPU (4GB RPi4?)

    Adding zram may mean more RAM appears to be available to applications, but it will also consume more CPU so what you gain on the one hand you lose on the other - you may have plenty of RAM available with zram but you may then experience stuttering during video playback as you are now CPU bound.

    Planning on using any form of swap is a bad idea, particularly if your swap file is stored on SD card - it will be very slow, with or without zswap. Swap should only be used as a last resort.

    There are several zram/zswap posts on the Raspberry Pi forum - this is probably one worth taking note of:

    swap in Raspbian: More trouble than it is worth? - Raspberry Pi Forums

    zram/zswap is a pretty niche requirement and not likely one that 99.99% of users will need. If you (or anyone else) wanted to test zram/zswap then the best option would be to enable the kernel configuration options and build your own custom/community LibreELEC: Compile [LibreELEC.wiki]

  • Easy enough to try. I use it on a 512MB H3 NanoPi M1. Not sure if it makes any difference, one way or the other.

    diff --git a/projects/Allwinner/linux/linux.arm.conf b/projects/Allwinner/linux/linux.arm.conf


  • natumbri your config diff is incomplete, you'll need a few more: http://ix.io/1wyu

    Nah, I don't think so. The only changes that you have and I don't, that actually do anything, are:


    With the default LZO-RLE, I don't think those are required? ([v3,0/7] lib/lzo: performance improvements - Patchwork) My kernel seems to be working just fine without them, in any event. The zram swap is reported as available (and is used from time to time), and the compression algorithm is reported as lzo-rle.

    But... I could be wrong: is there any way to check if it is *actually* working, or if it just *looks* like it is working?

    Also, maybe the switch to LZO-RLE (with the associated reduced processing overhead) is a reason to reconsider for LE? Processing overhead seems to be the main (*only* - but for that, why wouldn't you turn it on?) argument against implementing zram on LE. And that is much less of a problem with LZO-RLE.

    Or not. As has been mentioned, people who really want can always build it for themselves.



  • I am very inexperienced, I thought perhaps it may be useful to 'buy the developers' a few extra MB (50,100, 200?) to work with for room to move. Obviously you guys know your stuff very well. Wasn't sure if you had all heard of the technology at all.

    Regardless I have faith, LibreElec has been wonderful on my R.Pi3, it was only a suggestion, thank you all for the hard work.

  • Hey, so the memory issues on 1GB raspberry pi 4's seem to make this a viable option at least to try. Could anyone give me the dummies version of how to do this on a pi? (I've currently had to resort to using swap, and that does make my pi rock solid, but I would rather a solution that traded some cpu cycles instead of wear on my SD card).
    Thanks for any advice