Z3fold Allocator Slated For Removal From The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    Z3fold Allocator Slated For Removal From The Linux Kernel

    Phoronix: Z3fold Allocator Slated For Removal From The Linux Kernel

    The Z3fold allocator for compressed pages was quietly deprecated several months ago with users encouraged to use zsmalloc instead. With no one vocally objecting, the Z3fold allocator code is now being positioned for removal from the Linux kernel source tree...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • aviallon
    Senior Member
    • Dec 2022
    • 294

    #2
    Zswap is a very nice thing by the way.
    All of my servers have it enabled (with shrinker and zstd as compressor).
    It works wonder to reduce the space used by idle pages by a big factor (usually ~3x).

    Comment

    • skeevy420
      Senior Member
      • May 2017
      • 8664

      #3
      Code:
      zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=10 zswap.zpool=z3fold
      That sounds about right . . . What specific bugs?

      Comment

      • skeevy420
        Senior Member
        • May 2017
        • 8664

        #4
        Originally posted by aviallon View Post
        Zswap is a very nice thing by the way.
        All of my servers have it enabled (with shrinker and zstd as compressor).
        It works wonder to reduce the space used by idle pages by a big factor (usually ~3x).
        I don't want incoming data to be compressor throttled so I use LZ4.

        Comment

        • oibaf
          Senior Member
          • Feb 2008
          • 1223

          #5
          Originally posted by aviallon View Post
          Zswap is a very nice thing by the way.
          All of my servers have it enabled (with shrinker and zstd as compressor).
          It works wonder to reduce the space used by idle pages by a big factor (usually ~3x).
          Actually I prefer to use zram, it does not need swap on SSD/HD, and in case of the SSD, it also preserve its life.

          Comment

          • archkde
            Senior Member
            • May 2019
            • 691

            #6
            Originally posted by skeevy420 View Post
            Code:
            zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=10 zswap.zpool=z3fold
            That sounds about right . . . What specific bugs?
            Just switch the pool to zsmalloc and you'll get better compression. You might also consider making the pool a bit larger, or switching the compressor to zstd if you're regularly hitting the disk.

            Comment

            • soulsource
              Senior Member
              • Aug 2014
              • 215

              #7
              I prefer getting it removed to leaving it in in its current, broken state. Getting a kernel panic during a long-running compile task is not fun.

              Comment

              • caligula
                Senior Member
                • Jan 2014
                • 3342

                #8
                I think this zswap/zram/zfold thing is one of the most confusing things in kernel configuration. Nobody tells you what all these options are.

                Comment

                • sobrus
                  Senior Member
                  • Apr 2021
                  • 191

                  #9
                  Originally posted by oibaf View Post

                  Actually I prefer to use zram, it does not need swap on SSD/HD, and in case of the SSD, it also preserve its life.
                  Same here. Also, it's worth noting that enabling zram is not enough. You also need to disable zswap.
                  And that zram can also using backing block device (can be a file) to get rid of cold pages to disk (but still this doesn't wear ssd much)

                  Comment

                  • moonwalker
                    Senior Member
                    • Dec 2013
                    • 236

                    #10
                    Originally posted by caligula View Post
                    I think this zswap/zram/zfold thing is one of the most confusing things in kernel configuration. Nobody tells you what all these options are.
                    It is incorrect to compare z3fold (rather than zfold) with either zswap or zram, as it is an allocator for zswap, puts three compressed pages in one. Other alternatives are zbud (two compressed pages in one, least efficient) and zsmalloc (AFAIK most efficient).

                    zswap is a component that compresses the memory pages instead of pushing them to on-disk swap if they are highly compressible, reducing disk I/O at the cost of a bit higher CPU usage. The downside is that those pages have to be uncompressed anyway if system becomes so memory-starved that even those compressible pages have to be pushed out to on-disk swap.

                    Finally, zram is an in-RAM virtual block device of fixed size that compresses down to much smaller actual memory use, depending on what you put in it. It can be used for any data that can be put on disks, except it would be lost on shutdown/reboot/power loss. Most common use for zram is to use it as swap device, effectively just compressing all the memory pages that would be paged out to disk instead.

                    As to zram vs zswap - really it comes down to your use case. Speaking for my own usage patterns and hardware, I prefer to use zram over zswap because in my experience zswap worst case performance seems to use up both CPU and disk I/O and performance degradation seems to be even more sudden than with traditional on-disk swap. zram seems to offer the smoothest performance degradation, but it also has harder limits on memory use (on-disk swap gives near limitless memory). zram also makes hibernation a bit more difficult to get working, as you need to activate your on-disk swap used as resume device only immediately before hibernation (you can create systemd service unit for that, or for SysV-based systems you may be able to use PM hook) and deactivate it after resuming from hibernation, and you need to make sure that on-disk swap device for hibernation is always activated with the highest possible priority (32767), otherwise if you have lots of incompressible pages in memory the system will fail to free up enough RAM (needs about 50%, according to kernel's PCI PM code documentation) to create resume image. For the record, my configuration for zram is single device using zstd compressor, 4xRAM in size (typical compression I see in my use exceeds 5x). Though in production on the workstations we deploy we use the more conservative 2xRAM sizing.

                    Comment

                    Working...
                    X