| 1 | ========================================
|
| 2 | zram: Compressed RAM-based block devices
|
| 3 | ========================================
|
| 4 |
|
| 5 | Introduction
|
| 6 | ============
|
| 7 |
|
| 8 | The zram module creates RAM-based block devices named /dev/zram<id>
|
| 9 | (<id> = 0, 1, ...). Pages written to these disks are compressed and stored
|
| 10 | in memory itself. These disks allow very fast I/O and compression provides
|
| 11 | good amounts of memory savings. Some of the use cases include /tmp storage,
|
| 12 | use as swap disks, various caches under /var and maybe many more. :)
|
| 13 |
|
| 14 | Statistics for individual zram devices are exported through sysfs nodes at
|
| 15 | /sys/block/zram<id>/
|
| 16 |
|
| 17 | Usage
|
| 18 | =====
|
| 19 |
|
| 20 | There are several ways to configure and manage zram device(-s):
|
| 21 |
|
| 22 | a) using zram and zram_control sysfs attributes
|
| 23 | b) using zramctl utility, provided by util-linux ([email protected]).
|
| 24 |
|
| 25 | In this document we will describe only 'manual' zram configuration steps,
|
| 26 | IOW, zram and zram_control sysfs attributes.
|
| 27 |
|
| 28 | In order to get a better idea about zramctl please consult util-linux
|
| 29 | documentation, zramctl man-page or `zramctl --help`. Please be informed
|
| 30 | that zram maintainers do not develop/maintain util-linux or zramctl, should
|
| 31 | you have any questions please contact [email protected]
|
| 32 |
|
| 33 | Following shows a typical sequence of steps for using zram.
|
| 34 |
|
| 35 | WARNING
|
| 36 | =======
|
| 37 |
|
| 38 | For the sake of simplicity we skip error checking parts in most of the
|
| 39 | examples below. However, it is your sole responsibility to handle errors.
|
| 40 |
|
| 41 | zram sysfs attributes always return negative values in case of errors.
|
| 42 | The list of possible return codes:
|
| 43 |
|
| 44 | ======== =============================================================
|
| 45 | -EBUSY an attempt to modify an attribute that cannot be changed once
|
| 46 | the device has been initialised. Please reset device first.
|
| 47 | -ENOMEM zram was not able to allocate enough memory to fulfil your
|
| 48 | needs.
|
| 49 | -EINVAL invalid input has been provided.
|
| 50 | -EAGAIN re-try operation later (e.g. when attempting to run recompress
|
| 51 | and writeback simultaneously).
|
| 52 | ======== =============================================================
|
| 53 |
|
| 54 | If you use 'echo', the returned value is set by the 'echo' utility,
|
| 55 | and, in general case, something like::
|
| 56 |
|
| 57 | echo foo > /sys/block/zram0/comp_algorithm
|
| 58 | if [ $? -ne 0 ]; then
|
| 59 | handle_error
|
| 60 | fi
|
| 61 |
|
| 62 | should suffice.
|
| 63 |
|
| 64 | Load Module
|
| 65 | ===========
|
| 66 |
|
| 67 | ::
|
| 68 |
|
| 69 | modprobe zram num_devices=4
|
| 70 |
|
| 71 | This creates 4 devices: /dev/zram{0,1,2,3}
|
| 72 |
|
| 73 | num_devices parameter is optional and tells zram how many devices should be
|
| 74 | pre-created. Default: 1.
|
| 75 |
|
| 76 | Select compression algorithm
|
| 77 | ============================
|
| 78 |
|
| 79 | Using comp_algorithm device attribute one can see available and
|
| 80 | currently selected (shown in square brackets) compression algorithms,
|
| 81 | or change the selected compression algorithm (once the device is initialised
|
| 82 | there is no way to change compression algorithm).
|
| 83 |
|
| 84 | Examples::
|
| 85 |
|
| 86 | #show supported compression algorithms
|
| 87 | cat /sys/block/zram0/comp_algorithm
|
| 88 | lzo [lz4]
|
| 89 |
|
| 90 | #select lzo compression algorithm
|
| 91 | echo lzo > /sys/block/zram0/comp_algorithm
|
| 92 |
|
| 93 | For the time being, the `comp_algorithm` content shows only compression
|
| 94 | algorithms that are supported by zram.
|
| 95 |
|
| 96 | Set compression algorithm parameters: Optional
|
| 97 | ==============================================
|
| 98 |
|
| 99 | Compression algorithms may support specific parameters which can be
|
| 100 | tweaked for particular dataset. ZRAM has an `algorithm_params` device
|
| 101 | attribute which provides a per-algorithm params configuration.
|
| 102 |
|
| 103 | For example, several compression algorithms support `level` parameter.
|
| 104 | In addition, certain compression algorithms support pre-trained dictionaries,
|
| 105 | which significantly change algorithms' characteristics. In order to configure
|
| 106 | compression algorithm to use external pre-trained dictionary, pass full
|
| 107 | path to the `dict` along with other parameters::
|
| 108 |
|
| 109 | #pass path to pre-trained zstd dictionary
|
| 110 | echo "algo=zstd dict=/etc/dictionary" > /sys/block/zram0/algorithm_params
|
| 111 |
|
| 112 | #pass path to pre-trained zstd dictionary and compression level
|
| 113 | echo "algo=zstd level=8 dict=/etc/dictionary" > \
|
| 114 | /sys/block/zram0/algorithm_params
|
| 115 |
|
| 116 | #same, but using algorithm priority
|
| 117 | echo "algo=zstd priority=1" > /sys/block/zram0/recomp_algorithm
|
| 118 | echo "priority=1 dict=/etc/dictionary" > \
|
| 119 | /sys/block/zram0/algorithm_params
|
| 120 |
|
| 121 | Each write to `algorithm_params` replaces the entire set of parameters of
|
| 122 | the corresponding algorithm, parameters that are not listed in the write
|
| 123 | are reset to their default values. Configure all of the parameters of an
|
| 124 | algorithm in one write::
|
| 125 |
|
| 126 | #WRONG: the second write resets level back to its default value
|
| 127 | echo "algo=zstd level=8" > /sys/block/zram0/algorithm_params
|
| 128 | echo "algo=zstd dict=/etc/dictionary" > /sys/block/zram0/algorithm_params
|
| 129 |
|
| 130 | #RIGHT
|
| 131 | echo "algo=zstd level=8 dict=/etc/dictionary" > \
|
| 132 | /sys/block/zram0/algorithm_params
|
| 133 |
|
| 134 | Select the compression algorithm before configuring its parameters. The
|
| 135 | parameters of one algorithm are not necessarily valid for another one, so
|
| 136 | changing the algorithm of a particular priority resets that priority's
|
| 137 | parameters::
|
| 138 |
|
| 139 | #WRONG: comp_algorithm write resets the previously configured level
|
| 140 | echo "level=8" > /sys/block/zram0/algorithm_params
|
| 141 | echo zstd > /sys/block/zram0/comp_algorithm
|
| 142 |
|
| 143 | #RIGHT
|
| 144 | echo zstd > /sys/block/zram0/comp_algorithm
|
| 145 | echo "algo=zstd level=8" > /sys/block/zram0/algorithm_params
|
| 146 |
|
| 147 | Parameters are algorithm specific: not all algorithms support pre-trained
|
| 148 | dictionaries, not all algorithms support `level`. Furthermore, for certain
|
| 149 | algorithms `level` controls the compression level (the higher the value the
|
| 150 | better the compression ratio, it even can take negatives values for some
|
| 151 | algorithms), for other algorithms `level` is acceleration level (the higher
|
| 152 | the value the lower the compression ratio).
|
| 153 |
|
| 154 | Parameters are handed over to the compression algorithm when the device is
|
| 155 | initialised, hence invalid parameters (or parameters that the selected
|
| 156 | algorithm does not support) are reported by the `disksize` write, and not
|
| 157 | by the `algorithm_params` write that has configured them.
|
| 158 |
|
| 159 | Set Disksize
|
| 160 | ============
|
| 161 |
|
| 162 | Set disk size by writing the value to sysfs node 'disksize'.
|
| 163 | The value can be either in bytes or you can use mem suffixes.
|
| 164 | Examples::
|
| 165 |
|
| 166 | # Initialize /dev/zram0 with 50MB disksize
|
| 167 | echo $((50*1024*1024)) > /sys/block/zram0/disksize
|
| 168 |
|
| 169 | # Using mem suffixes
|
| 170 | echo 256K > /sys/block/zram0/disksize
|
| 171 | echo 512M > /sys/block/zram0/disksize
|
| 172 | echo 1G > /sys/block/zram0/disksize
|
| 173 |
|
| 174 | Note:
|
| 175 | There is little point creating a zram of greater than twice the size of memory
|
| 176 | since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
|
| 177 | size of the disk when not in use so a huge zram is wasteful.
|
| 178 |
|
| 179 | Set memory limit: Optional
|
| 180 | ==========================
|
| 181 |
|
| 182 | Set memory limit by writing the value to sysfs node 'mem_limit'.
|
| 183 | The value can be either in bytes or you can use mem suffixes.
|
| 184 | In addition, you could change the value in runtime.
|
| 185 | Examples::
|
| 186 |
|
| 187 | # limit /dev/zram0 with 50MB memory
|
| 188 | echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
|
| 189 |
|
| 190 | # Using mem suffixes
|
| 191 | echo 256K > /sys/block/zram0/mem_limit
|
| 192 | echo 512M > /sys/block/zram0/mem_limit
|
| 193 | echo 1G > /sys/block/zram0/mem_limit
|
| 194 |
|
| 195 | # To disable memory limit
|
| 196 | echo 0 > /sys/block/zram0/mem_limit
|
| 197 |
|
| 198 | Activate
|
| 199 | ========
|
| 200 |
|
| 201 | ::
|
| 202 |
|
| 203 | mkswap /dev/zram0
|
| 204 | swapon /dev/zram0
|
| 205 |
|
| 206 | mkfs.ext4 /dev/zram1
|
| 207 | mount /dev/zram1 /tmp
|
| 208 |
|
| 209 | Add/remove zram devices
|
| 210 | =======================
|
| 211 |
|
| 212 | zram provides a control interface, which enables dynamic (on-demand) device
|
| 213 | addition and removal.
|
| 214 |
|
| 215 | In order to add a new /dev/zramX device, perform a read operation on the hot_add
|
| 216 | attribute. This will return either the new device's device id (meaning that you
|
| 217 | can use /dev/zram<id>) or an error code.
|
| 218 |
|
| 219 | Example::
|
| 220 |
|
| 221 | cat /sys/class/zram-control/hot_add
|
| 222 | 1
|
| 223 |
|
| 224 | To remove the existing /dev/zramX device (where X is a device id)
|
| 225 | execute::
|
| 226 |
|
| 227 | echo X > /sys/class/zram-control/hot_remove
|
| 228 |
|
| 229 | Stats
|
| 230 | =====
|
| 231 |
|
| 232 | Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
| 233 |
|
| 234 | A brief description of exported device attributes follows. For more details
|
| 235 | please read Documentation/ABI/testing/sysfs-block-zram.
|
| 236 |
|
| 237 | ====================== ====== ===============================================
|
| 238 | Name access description
|
| 239 | ====================== ====== ===============================================
|
| 240 | disksize RW show and set the device's disk size
|
| 241 | initstate RO shows the initialization state of the device
|
| 242 | reset WO trigger device reset
|
| 243 | mem_used_max WO reset the `mem_used_max` counter (see later)
|
| 244 | mem_limit WO specifies the maximum amount of memory ZRAM can
|
| 245 | use to store the compressed data
|
| 246 | writeback_limit WO specifies the maximum amount of write IO zram
|
| 247 | can write out to backing device as 4KB unit
|
| 248 | writeback_limit_enable RW show and set writeback_limit feature
|
| 249 | writeback_batch_size RW show and set maximum number of in-flight
|
| 250 | writeback operations
|
| 251 | compressed_writeback RW show and set compressed writeback feature
|
| 252 | comp_algorithm RW show and change the compression algorithm
|
| 253 | algorithm_params WO setup compression algorithm parameters
|
| 254 | compact WO trigger memory compaction
|
| 255 | debug_stat RO this file is used for zram debugging purposes
|
| 256 | backing_dev RW set up backend storage for zram to write out
|
| 257 | idle WO mark allocated slot as idle
|
| 258 | ====================== ====== ===============================================
|
| 259 |
|
| 260 | User space is advised to use the following files to read the device statistics.
|
| 261 |
|
| 262 | File /sys/block/zram<id>/stat
|
| 263 |
|
| 264 | Represents block layer statistics. Read Documentation/block/stat.rst for
|
| 265 | details.
|
| 266 |
|
| 267 | File /sys/block/zram<id>/io_stat
|
| 268 |
|
| 269 | The stat file represents device's I/O statistics not accounted by block
|
| 270 | layer and, thus, not available in zram<id>/stat file. It consists of a
|
| 271 | single line of text and contains the following stats separated by
|
| 272 | whitespace:
|
| 273 |
|
| 274 | ============= =============================================================
|
| 275 | failed_reads The number of failed reads
|
| 276 | failed_writes The number of failed writes
|
| 277 | invalid_io The number of non-page-size-aligned I/O requests
|
| 278 | notify_free Depending on device usage scenario it may account
|
| 279 |
|
| 280 | a) the number of pages freed because of swap slot free
|
| 281 | notifications
|
| 282 | b) the number of pages freed because of
|
| 283 | REQ_OP_DISCARD requests sent by bio. The former ones are
|
| 284 | sent to a swap block device when a swap slot is freed,
|
| 285 | which implies that this disk is being used as a swap disk.
|
| 286 |
|
| 287 | The latter ones are sent by filesystem mounted with
|
| 288 | discard option, whenever some data blocks are getting
|
| 289 | discarded.
|
| 290 | ============= =============================================================
|
| 291 |
|
| 292 | File /sys/block/zram<id>/mm_stat
|
| 293 |
|
| 294 | The mm_stat file represents the device's mm statistics. It consists of a single
|
| 295 | line of text and contains the following stats separated by whitespace:
|
| 296 |
|
| 297 | ================ =============================================================
|
| 298 | orig_data_size uncompressed size of data stored in this disk.
|
| 299 | Unit: bytes
|
| 300 | compr_data_size compressed size of data stored in this disk
|
| 301 | mem_used_total the amount of memory allocated for this disk. This
|
| 302 | includes allocator fragmentation and metadata overhead,
|
| 303 | allocated for this disk. So, allocator space efficiency
|
| 304 | can be calculated using compr_data_size and this statistic.
|
| 305 | Unit: bytes
|
| 306 | mem_limit the maximum amount of memory ZRAM can use to store
|
| 307 | the compressed data
|
| 308 | mem_used_max the maximum amount of memory zram has consumed to
|
| 309 | store the data
|
| 310 | same_pages the number of same element filled pages written to this disk.
|
| 311 | No memory is allocated for such pages.
|
| 312 | pages_compacted the number of pages freed during compaction
|
| 313 | huge_pages the number of incompressible pages
|
| 314 | huge_pages_since the number of incompressible pages since zram set up
|
| 315 | ================ =============================================================
|
| 316 |
|
| 317 | File /sys/block/zram<id>/bd_stat
|
| 318 |
|
| 319 | The bd_stat file represents a device's backing device statistics. It consists of
|
| 320 | a single line of text and contains the following stats separated by whitespace:
|
| 321 |
|
| 322 | ============== =============================================================
|
| 323 | bd_count size of data written in backing device.
|
| 324 | Unit: 4K bytes
|
| 325 | bd_reads the number of reads from backing device
|
| 326 | Unit: 4K bytes
|
| 327 | bd_writes the number of writes to backing device
|
| 328 | Unit: 4K bytes
|
| 329 | ============== =============================================================
|
| 330 |
|
| 331 | Deactivate
|
| 332 | ==========
|
| 333 |
|
| 334 | ::
|
| 335 |
|
| 336 | swapoff /dev/zram0
|
| 337 | umount /dev/zram1
|
| 338 |
|
| 339 | Reset
|
| 340 | =====
|
| 341 |
|
| 342 | Write any positive value to 'reset' sysfs node::
|
| 343 |
|
| 344 | echo 1 > /sys/block/zram0/reset
|
| 345 | echo 1 > /sys/block/zram1/reset
|
| 346 |
|
| 347 | This frees all the memory allocated for the given device and
|
| 348 | resets the disksize to zero. You must set the disksize again
|
| 349 | before reusing the device.
|
| 350 |
|
| 351 | Optional Feature
|
| 352 | ================
|
| 353 |
|
| 354 | IDLE pages tracking
|
| 355 | -------------------
|
| 356 |
|
| 357 | zram has built-in support for idle pages tracking (that is, allocated but
|
| 358 | not used pages). This feature is useful for e.g. zram writeback and
|
| 359 | recompression. In order to mark pages as idle, execute the following command::
|
| 360 |
|
| 361 | echo all > /sys/block/zramX/idle
|
| 362 |
|
| 363 | This will mark all allocated zram pages as idle. The idle mark will be
|
| 364 | removed only when the page (block) is accessed (e.g. overwritten or freed).
|
| 365 | Additionally, when CONFIG_ZRAM_TRACK_ENTRY_ACTIME is enabled, pages can be
|
| 366 | marked as idle based on how many seconds have passed since the last access to
|
| 367 | a particular zram page::
|
| 368 |
|
| 369 | echo 86400 > /sys/block/zramX/idle
|
| 370 |
|
| 371 | In this example, all pages which haven't been accessed in more than 86400
|
| 372 | seconds (one day) will be marked idle.
|
| 373 |
|
| 374 | writeback
|
| 375 | ---------
|
| 376 |
|
| 377 | With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
|
| 378 | to backing storage rather than keeping it in memory.
|
| 379 | To use the feature, admin should set up backing device via::
|
| 380 |
|
| 381 | echo /dev/sda5 > /sys/block/zramX/backing_dev
|
| 382 |
|
| 383 | before disksize setting. It supports only partitions at this moment.
|
| 384 | If admin wants to use incompressible page writeback, they could do it via::
|
| 385 |
|
| 386 | echo huge > /sys/block/zramX/writeback
|
| 387 |
|
| 388 | Admin can request writeback of idle pages at right timing via::
|
| 389 |
|
| 390 | echo idle > /sys/block/zramX/writeback
|
| 391 |
|
| 392 | With the command, zram will writeback idle pages from memory to the storage.
|
| 393 |
|
| 394 | Additionally, if a user choose to writeback only huge and idle pages
|
| 395 | this can be accomplished with::
|
| 396 |
|
| 397 | echo huge_idle > /sys/block/zramX/writeback
|
| 398 |
|
| 399 | If a user chooses to writeback only incompressible pages (pages that none of
|
| 400 | algorithms can compress) this can be accomplished with::
|
| 401 |
|
| 402 | echo incompressible > /sys/block/zramX/writeback
|
| 403 |
|
| 404 | If an admin wants to write a specific page in zram device to the backing device,
|
| 405 | they could write a page index into the interface::
|
| 406 |
|
| 407 | echo "page_index=1251" > /sys/block/zramX/writeback
|
| 408 |
|
| 409 | In Linux 6.16 this interface underwent some rework. First, the interface
|
| 410 | now supports `key=value` format for all of its parameters (`type=huge_idle`,
|
| 411 | etc.) Second, the support for `page_indexes` was introduced, which specify
|
| 412 | `LOW-HIGH` range (or ranges) of pages to be written-back. This reduces the
|
| 413 | number of syscalls, but more importantly this enables optimal post-processing
|
| 414 | target selection strategy. Usage example::
|
| 415 |
|
| 416 | echo "type=idle" > /sys/block/zramX/writeback
|
| 417 | echo "page_indexes=1-100 page_indexes=200-300" > \
|
| 418 | /sys/block/zramX/writeback
|
| 419 |
|
| 420 | We also now permit multiple page_index params per call and a mix of
|
| 421 | single pages and page ranges::
|
| 422 |
|
| 423 | echo page_index=42 page_index=99 page_indexes=100-200 \
|
| 424 | page_indexes=500-700 > /sys/block/zramX/writeback
|
| 425 |
|
| 426 | If there are lots of write IO with flash device, potentially, it has
|
| 427 | flash wearout problem so that admin needs to design write limitation
|
| 428 | to guarantee storage health for entire product life.
|
| 429 |
|
| 430 | To overcome the concern, zram supports "writeback_limit" feature.
|
| 431 | The "writeback_limit_enable"'s default value is 0 so that it doesn't limit
|
| 432 | any writeback. IOW, if admin wants to apply writeback budget, they should
|
| 433 | enable writeback_limit_enable via::
|
| 434 |
|
| 435 | $ echo 1 > /sys/block/zramX/writeback_limit_enable
|
| 436 |
|
| 437 | Once writeback_limit_enable is set, zram doesn't allow any writeback
|
| 438 | until admin sets the budget via /sys/block/zramX/writeback_limit.
|
| 439 |
|
| 440 | (If admin doesn't enable writeback_limit_enable, writeback_limit's value
|
| 441 | assigned via /sys/block/zramX/writeback_limit is meaningless.)
|
| 442 |
|
| 443 | If admin wants to limit writeback as per-day 400M, they could do it
|
| 444 | like below::
|
| 445 |
|
| 446 | $ MB_SHIFT=20
|
| 447 | $ 4K_SHIFT=12
|
| 448 | $ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
| 449 | /sys/block/zram0/writeback_limit.
|
| 450 | $ echo 1 > /sys/block/zram0/writeback_limit_enable
|
| 451 |
|
| 452 | If admins want to allow further write again once the budget is exhausted,
|
| 453 | they could do it like below::
|
| 454 |
|
| 455 | $ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
| 456 | /sys/block/zram0/writeback_limit
|
| 457 |
|
| 458 | If an admin wants to see the remaining writeback budget since last set::
|
| 459 |
|
| 460 | $ cat /sys/block/zramX/writeback_limit
|
| 461 |
|
| 462 | If an admin wants to disable writeback limit, they could do::
|
| 463 |
|
| 464 | $ echo 0 > /sys/block/zramX/writeback_limit_enable
|
| 465 |
|
| 466 | The writeback_limit count will reset whenever you reset zram (e.g.,
|
| 467 | system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of
|
| 468 | writeback happened until you reset the zram to allocate extra writeback
|
| 469 | budget in next setting is user's job.
|
| 470 |
|
| 471 | By default zram stores written back pages in decompressed (raw) form, which
|
| 472 | means that writeback operation involves decompression of the page before
|
| 473 | writing it to the backing device. This behavior can be changed by enabling
|
| 474 | `compressed_writeback` feature, which causes zram to write compressed pages
|
| 475 | to the backing device, thus avoiding decompression overhead. To enable
|
| 476 | this feature, execute::
|
| 477 |
|
| 478 | $ echo yes > /sys/block/zramX/compressed_writeback
|
| 479 |
|
| 480 | Note that this feature should be configured before the `zramX` device is
|
| 481 | initialized.
|
| 482 |
|
| 483 | Depending on backing device storage type, writeback operation may benefit
|
| 484 | from a higher number of in-flight write requests (batched writes). The
|
| 485 | number of maximum in-flight writeback operations can be configured via
|
| 486 | `writeback_batch_size` attribute. To change the default value (which is 32),
|
| 487 | execute::
|
| 488 |
|
| 489 | $ echo 64 > /sys/block/zramX/writeback_batch_size
|
| 490 |
|
| 491 | If admin wants to measure writeback count in a certain period, they could
|
| 492 | know it via /sys/block/zram0/bd_stat's 3rd column.
|
| 493 |
|
| 494 | recompression
|
| 495 | -------------
|
| 496 |
|
| 497 | With `CONFIG_ZRAM_MULTI_COMP`, zram can recompress pages using alternative
|
| 498 | (secondary) compression algorithms. The basic idea is that alternative
|
| 499 | compression algorithm can provide better compression ratio at a price of
|
| 500 | (potentially) slower compression/decompression speeds. Alternative compression
|
| 501 | algorithm can, for example, be more successful compressing huge pages (those
|
| 502 | that default algorithm failed to compress). Another application is idle pages
|
| 503 | recompression - pages that are cold and sit in the memory can be recompressed
|
| 504 | using more effective algorithm and, hence, reduce zsmalloc memory usage.
|
| 505 |
|
| 506 | With `CONFIG_ZRAM_MULTI_COMP`, zram supports up to 4 compression algorithms:
|
| 507 | one primary and up to 3 secondary ones. Primary zram compressor is explained
|
| 508 | in "3) Select compression algorithm", secondary algorithms are configured
|
| 509 | using recomp_algorithm device attribute.
|
| 510 |
|
| 511 | Example:::
|
| 512 |
|
| 513 | #show supported recompression algorithms
|
| 514 | cat /sys/block/zramX/recomp_algorithm
|
| 515 | #1: lzo lzo-rle lz4 lz4hc [zstd]
|
| 516 | #2: lzo lzo-rle lz4 [lz4hc] zstd
|
| 517 |
|
| 518 | Alternative compression algorithms are sorted by priority. In the example
|
| 519 | above, zstd is used as the first alternative algorithm, which has priority
|
| 520 | of 1, while lz4hc is configured as a compression algorithm with priority 2.
|
| 521 | Alternative compression algorithm's priority is provided during algorithms
|
| 522 | configuration:::
|
| 523 |
|
| 524 | #select zstd recompression algorithm, priority 1
|
| 525 | echo "algo=zstd priority=1" > /sys/block/zramX/recomp_algorithm
|
| 526 |
|
| 527 | #select deflate recompression algorithm, priority 2
|
| 528 | echo "algo=deflate priority=2" > /sys/block/zramX/recomp_algorithm
|
| 529 |
|
| 530 | Another device attribute that `CONFIG_ZRAM_MULTI_COMP` enables is `recompress`,
|
| 531 | which controls recompression.
|
| 532 |
|
| 533 | Examples:::
|
| 534 |
|
| 535 | #IDLE pages recompression is activated by `idle` mode
|
| 536 | echo "type=idle priority=1" > /sys/block/zramX/recompress
|
| 537 |
|
| 538 | #HUGE pages recompression is activated by `huge` mode
|
| 539 | echo "type=huge priority=2" > /sys/block/zram0/recompress
|
| 540 |
|
| 541 | #HUGE_IDLE pages recompression is activated by `huge_idle` mode
|
| 542 | echo "type=huge_idle priority=1" > /sys/block/zramX/recompress
|
| 543 |
|
| 544 | The number of idle pages can be significant, so user-space can pass a size
|
| 545 | threshold (in bytes) to the recompress knob: zram will recompress only pages
|
| 546 | of equal or greater size:::
|
| 547 |
|
| 548 | #recompress all pages larger than 3000 bytes
|
| 549 | echo "threshold=3000 priority=1" > /sys/block/zramX/recompress
|
| 550 |
|
| 551 | #recompress idle pages larger than 2000 bytes
|
| 552 | echo "type=idle threshold=2000 priority=1" > \
|
| 553 | /sys/block/zramX/recompress
|
| 554 |
|
| 555 | It is also possible to limit the number of pages zram re-compression will
|
| 556 | attempt to recompress:::
|
| 557 |
|
| 558 | echo "type=huge_idle priority=1 max_pages=42" > \
|
| 559 | /sys/block/zramX/recompress
|
| 560 |
|
| 561 | It is advised to always specify `priority` parameter. While it is also
|
| 562 | possible to specify `algo` parameter, so that `zram` will use algorithm's
|
| 563 | name to determine the priority, it is not recommended, since it can lead to
|
| 564 | unexpected results when the same algorithm is configured with different
|
| 565 | priorities (e.g. different parameters). `priority` is the only way to
|
| 566 | guarantee that the expected algorithm will be used.
|
| 567 |
|
| 568 | memory tracking
|
| 569 | ===============
|
| 570 |
|
| 571 | With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
|
| 572 | zram block. It could be useful to catch cold or incompressible
|
| 573 | pages of the process with*pagemap.
|
| 574 |
|
| 575 | If you enable the feature, you could see block state via
|
| 576 | /sys/kernel/debug/zram/zram0/block_state". The output is as follows::
|
| 577 |
|
| 578 | 300 75.033841 .wh...
|
| 579 | 301 63.806904 s.....
|
| 580 | 302 63.806919 ..hi..
|
| 581 | 303 62.801919 ....r.
|
| 582 | 304 146.781902 ..hi.n
|
| 583 |
|
| 584 | First column
|
| 585 | zram's block index.
|
| 586 | Second column
|
| 587 | access time since the system was booted
|
| 588 | Third column
|
| 589 | state of the block:
|
| 590 |
|
| 591 | s:
|
| 592 | same page
|
| 593 | w:
|
| 594 | written page to backing store
|
| 595 | h:
|
| 596 | huge page
|
| 597 | i:
|
| 598 | idle page
|
| 599 | r:
|
| 600 | recompressed page (secondary compression algorithm)
|
| 601 | n:
|
| 602 | none (including secondary) of algorithms could compress it
|
| 603 |
|
| 604 | First line of above example says 300th block is accessed at 75.033841sec
|
| 605 | and the block's state is huge so it is written back to the backing
|
| 606 | storage. It's a debugging feature so anyone shouldn't rely on it to work
|
| 607 | properly.
|
| 608 |
|
| 609 | Nitin Gupta
|
| 610 | [email protected]
|