Announcement

Collapse
No announcement yet.

ZRAM Finally Promoted Out Of Staging In Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ZRAM Finally Promoted Out Of Staging In Linux Kernel

    Phoronix: ZRAM Finally Promoted Out Of Staging In Linux Kernel

    ZRAM has finally been promoted out of staging and into the main area of the Linux kernel within the block subsystem...

    http://www.phoronix.com/vr.php?view=MTU0NzA

  • #2
    sweet !

    Comment


    • #3
      hopefully it has an lz4 plugin which shouldn't have much if any peformance hit. i'm using lz4 in my application and its fast fast. Problem is the actual memory allocation/deallocation overhead is hurting me much worse than the compression/decompression. I'm testing very heavy thread loads with 40 hardware threads.
      Last edited by bnolsen; 12-18-2013, 10:48 PM.

      Comment


      • #4
        Originally posted by bnolsen View Post
        hopefully it has an lz4 plugin which shouldn't have much if any peformance hit. i'm using lz4 in my application and its fast fast. Problem is the actual memory allocation/deallocation overhead is hurting me much worse than the compression/decompression. I'm testing very heavy thread loads with 40 hardware threads.
        Zram does not support all the available compression plugins AFAICT. (it's being worked on).

        However, I have been googling around and you can use zswap with some parameters to get the same result. Mount the TMPFS FS with the memory restrains u used on the ZRAM blocks.

        Code:
        zswap.enabled=1 zswap.max_pool_percent=100 zswap.compressor=lz4
        And then use TMPFS instead of a FS on a ZRAM backed block device.

        I'm seriously confused why these things have to be two seperate implementations. The only thing ZRAM adds over ZSWAP is that it exposes the RAM as a block device. That is all. But hey, I'm just an end-use who am I to argue? .

        Comment


        • #5
          Originally posted by Rexilion View Post
          I'm seriously confused why these things have to be two seperate implementations. The only thing ZRAM adds over ZSWAP is that it exposes the RAM as a block device. That is all. But hey, I'm just an end-use who am I to argue? .
          One other advantage: zram does not require swap. You cannot use zswap on a swap-less computer, which makes it useless in embedded and running-in-RAM type scenarios. Your router cannot afford to use flash as swap, your thin client might not have a HD, etc.

          Comment


          • #6
            Originally posted by curaga View Post
            One other advantage: zram does not require swap. You cannot use zswap on a swap-less computer, which makes it useless in embedded and running-in-RAM type scenarios. Your router cannot afford to use flash as swap, your thin client might not have a HD, etc.
            What you said makes sense at first sight. However, zswap is capable of keeping 'swap in memory':

            Code:
            /* The maximum percentage of memory that the compressed pool can occupy */
            static unsigned int zswap_max_pool_percent = 20;
            module_param_named(max_pool_percent,
            			zswap_max_pool_percent, uint, 0644);
            I set this to 100 to only use 'real' swap as a last resort. I also turned off swap with 'swapoff -a' which succeeded without complaints. Maybe the term swap is not to be seen as something as a physical device containing contents that should belong in memory, but more as not directly accessible memory (i.e. compressed in this context).

            However, I'm in no way an expert in this so I might be way off base.

            The advantage of zswap in this regard is that compression will only happen once memory starts going low (vm.swappiness). As far as I know, zram always compresses the content you give it. Which in scenario's where a lot of memory is free, is not necessary.

            Comment


            • #7
              When you did swapoff -a, you also disabled zswap.

              As far as I know, the requirement for a backing "real" swap device for zswap still exists.

              http://stackoverflow.com/questions/1...zram-and-zswap
              https://www.kernel.org/doc/Documentation/vm/zswap.txt

              As far as I know, zram always compresses the content you give it.
              That's correct, but if you use zram as a swap device, it gets used only on memory pressure.

              Comment


              • #8
                Originally posted by curaga View Post
                When you did swapoff -a, you also disabled zswap.

                As far as I know, the requirement for a backing "real" swap device for zswap still exists.

                http://stackoverflow.com/questions/1...zram-and-zswap
                https://www.kernel.org/doc/Documentation/vm/zswap.txt
                I hope they will drop that requirement someday. Could be useful.

                Originally posted by curaga View Post
                That's correct, but if you use zram as a swap device, it gets used only on memory pressure.
                Using swap on a zram block is now superseeded by zswap requiring no new block device at all. I see no benefit in using zram in this scenario.

                See? This is why this topic is so confusing. Multiple approaches doing the same thing

                Comment


                • #9
                  It's only the same thing when you have real swap

                  Comment


                  • #10
                    Originally posted by Rexilion View Post
                    See? This is why this topic is so confusing. Multiple approaches doing the same thing
                    ZRAM is always going to store the block in its cache area even if it can't compress it. ZSwap will write such blocks out to swap.

                    Comment

                    Working...
                    X