LINUX.ORG.RU

Непонятки с zswap

 ,


1

4

И вот свершилось! 16 гигабайт начало не хватать.

Своп конечно помогает НО… говорят неплохо бы задействовать zswap дабы не убивать ssd почем зря, да и вообще полезно.

Прописываю zswap.enabled=1 в параметры ядра в Граб, как написано на АрчВики, делаю update-grub, перезагружаюсь и …

Короче cat /sys/module/zswap/parameters/enabled показывает N.

dmesg | grep zswap говорит zswap: loaded using pool zstd/zsmalloc

А grep -r . /sys/kernel/debug/zswap выдает

/sys/kernel/debug/zswap/stored_pages:0
/sys/kernel/debug/zswap/pool_total_size:0
/sys/kernel/debug/zswap/written_back_pages:0
/sys/kernel/debug/zswap/decompress_fail:0
/sys/kernel/debug/zswap/reject_compress_poor:0
/sys/kernel/debug/zswap/reject_compress_fail:0
/sys/kernel/debug/zswap/reject_kmemcache_fail:0
/sys/kernel/debug/zswap/reject_alloc_fail:0
/sys/kernel/debug/zswap/reject_reclaim_fail:0
/sys/kernel/debug/zswap/pool_limit_hit:0

В общем судя по всему таки не работает.

ЧЯДНТ?

как написано на АрчВики

Та же арчвики говорит:

в официально поддерживаемых ядрах по умолчанию включен zswap. Это можно проверить с помощью zgrep CONFIG_ZSWAP_DEFAULT_ON /proc/config.gz.

krasnh ★★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)

Короче решение таки нашел, но странное.

Пришлось создать файл /etc/tmpfiles.d/90-enable-zswap.conf

С таким содержанием: w! /sys/module/zswap/parameters/enabled - - - - 1

Нашел инструкцию как отключить zswap где то в тырнетах и сделал противоположное.) Вроде даже работает.

Есть у кого рекомендации по настройке, раз уж речь зашла?

Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от Vochatrak-az-ezm

Сдаётся, вы не договариваете вывод dmesg | grep zswap и там чего-то не хватает. Например, встроенного в ядро zstd не модулем в момент инициализации.

grep -e ZSWAP -e CONFIG_CRYPTO_ZSTD /boot/config-* или где там в Арче конфиг.

anonymous
()
Ответ на: комментарий от anonymous
zcat /proc/config.gz | grep ZSWAP

CONFIG_ZSWAP=y
CONFIG_ZSWAP_DEFAULT_ON=y
CONFIG_ZSWAP_SHRINKER_DEFAULT_ON=y
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_DEFLATE is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZO is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_842 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4HC is not set
CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
CONFIG_ZSWAP_COMPRESSOR_DEFAULT="zstd"
CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC=y
CONFIG_ZSWAP_ZPOOL_DEFAULT="zsmalloc"
dmesg | grep zswap

[    0.000000] Command line: BOOT_IMAGE=/@/boot/vmlinuz-linux-cachyos-bore-lto root=UUID=71f7da89-6dfb-44da-9029-6f2fa482fa95 rw rootflags=subvol=@ rd.driver.pre=vfio-pci amd_iommu=on iommu=pt quiet splash loglevel=3 audit=0 nvme_load=yes clearcpuid=514 zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=30
[    0.037612] Kernel command line: BOOT_IMAGE=/@/boot/vmlinuz-linux-cachyos-bore-lto root=UUID=71f7da89-6dfb-44da-9029-6f2fa482fa95 rw rootflags=subvol=@ rd.driver.pre=vfio-pci amd_iommu=on iommu=pt quiet splash loglevel=3 audit=0 nvme_load=yes clearcpuid=514 zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=30
[    2.567180] zswap: loaded using pool zstd/zsmalloc

Оно?

Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от anonymous
zcat /proc/config.gz | grep ZSTD 

CONFIG_HAVE_KERNEL_ZSTD=y
CONFIG_KERNEL_ZSTD=y
CONFIG_RD_ZSTD=y
CONFIG_MODULE_COMPRESS_ZSTD=y
CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
CONFIG_FW_LOADER_COMPRESS_ZSTD=y
CONFIG_ZRAM_BACKEND_ZSTD=y
CONFIG_ZRAM_DEF_COMP_ZSTD=y
CONFIG_F2FS_FS_ZSTD=y
CONFIG_UBIFS_FS_ZSTD=y
CONFIG_SQUASHFS_ZSTD=y
CONFIG_EROFS_FS_ZIP_ZSTD=y
CONFIG_CRYPTO_ZSTD=y
CONFIG_ZSTD_COMMON=y
CONFIG_ZSTD_COMPRESS=y
CONFIG_ZSTD_DECOMPRESS=y
CONFIG_DECOMPRESS_ZSTD=y
# CONFIG_DEBUG_INFO_COMPRESSED_ZSTD is not set
Vochatrak-az-ezm ★★
() автор топика
Ответ на: комментарий от Vochatrak-az-ezm

Загадка! Всё включено само и вообще не должно требовать дополнительных параметров.

Неочевидный момент: на десктопе с взрывной нагрузкой гибридный zram может быть эффективнее zswap — при высоком давлении zram не занимается распаковой сжатых данных для скидывания вниз, в отличие от zswap. При этом zram упаковывает данные лучше, чем zsmalloc и тем более z3fold.

У меня так:

$ sudo swapon --show
NAME           TYPE      SIZE USED PRIO
/dev/zram0     partition  20G   4G  100
/dev/nvme0n1p3 partition 8,9G   0B   10
/dev/nvme1n1p3 partition 8,9G   0B   10

Рекомендую попробовать оба варианта со stress-ng --vm 4 --vm-bytes 200% --vm-keep -t 300 и посмотреть, где система лучше будет отзываться в обычных приложениях.

anonymous
()
Ответ на: комментарий от anonymous

zswap примочка в ядре, она используется автоматически дополнительно к физическому zswap.16 ггигов ОЗУ не хватает?У меня 8 и мне не только не хватает, но еще и остаток остается.

nicholas_ru
()

Прописываю zswap.enabled=1 в параметры ядра в Граб, как написано на АрчВики, делаю update-grub, перезагружаюсь и …

Короче cat /sys/module/zswap/parameters/enabled показывает N.

То ли граб, то ли ядро, то ли системд считают себя самыми умными и сбрасывают часть параметров ядра. Или же в какой то момент (на 4.4 всё ОК) модуль стал слишком тупым и делает enable до загрузки модуля, выдаёт ошибку и забивает.

Активируй zswap и настройки на позднем этапе, например через rc.local.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Неочевидный момент: на десктопе с взрывной нагрузкой гибридный zram может быть эффективнее zswap — при высоком давлении zram не занимается распаковой сжатых данных для скидывания вниз, в отличие от zswap.

Спорный момент при быстром SSD. Диску важнее iops'ы, а шина (если это не топоая железка) недогружена. Короче быстрее поднять уже разжатю страницу с диска чем поднять сжатую и ждать распаковки.

Но зато zram + backind_dev выигрывает в скорости когда преобладает сброс в своп, например открытия вкладок браузера пакетами. Но разница не сильно большая, проценты.

Не забывай что zram без backind_dev сливается как только пул в оперативке кончится. А zswap работает всегда однаково, и с какой то версии вроде как научился работать без физического свопа - так же как zram. У них сейчас должен быть полный паритет +/- пара процентов в зависимости от сценария.

При этом zram упаковывает данные лучше, чем zsmalloc и тем более z3fold.

Почему это? zsmalloc это полностью плотная упаковка, как я zram. В zram алгоритмы умнее, но оверхед на эмуляцию блочного устройства. А компрессоры одинаково жмут что там что там.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Ни в коем случае! zram с выделенным физическим разделом для backing_dev (это его собственный своп), а физический своп с низким приоритетом - для гибернации. Иначе в высокоприоритетном zram в оперативке накопятся «мёртвые» данные и там либо свопить подсистему свопа, либо просто жить в уменьшеной оперативке.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Лучше трешинг при открытии новой вкладки в браузере?

В гибридном zram худшее, что случится: swap на диске будет использоваться как swap, даже с пугалкой LRU cache inversion. Если достаточно объёма zram на основную нагрузку, этого вообще не произойдёт. Не надо путать нормальный swap с zram backing device.

С zswap худшее: при открытии вкладки браузера процессорное время тратится на распаковку и перекидывание данных вниз, а не на пользовательскую задачу.

zswap отлично подходит для сервера, где нужно сгладить и буфферизовать свапинг и средняя полоса пропускания важнее задержек. А для десктопа — stress-ng рассудит.

anonymous
()
Ответ на: комментарий от anonymous

Лучше трешинг при открытии новой вкладки в браузере?

Как раз чтобы уменьшить трешинг при открытии новой вкладки - надо чтобы забитый предыдущими zram не мешался в оперативке. И тут одно из двух: или сразу использовать zswap, или backing_dev, куда zram сбросит лишнее.

В гибридном zram худшее, что случится: swap на диске будет использоваться как swap

То что ты называешь «гибридным зсвоп» это самый обычный зсвоп.

И да, «худший» сценарий это когда зсвоп вышел из чата и утянул за собой порядка трети физической оперативки.

С zswap худшее: при открытии вкладки браузера процессорное время тратится на распаковку и перекидывание данных вниз, а не на пользовательскую задачу

А при использовании zram оно не тратится? Страницы сжимаются, все тесты указывают на то что это выгодно. Разумеется то что сжато - когда либо придётся распаковать! Можно заранее, можно потом, при запросе. В чём принципиальная разница? В первом случае больше задержка при сбросе на диск, во втором при чтении с него. При трешинге - вообще без разницы.

Насчёт затрат процессорного времени - вообще смешно. Он использует не lzma и не gzip, там либо на порядки более быстрые lz4/lzo,либо кошмарно тяжёлый, но всё ещё на порядок более быстрый zstd, который всё ещё не вызывает видимого повышения нагрузки на цпу и часто даже лучше сокращает время выполнения задачи.

Блин, когда процесс запросил данные из памяти а его попросили подождать их загрузки - процессор уже по определению нифига полезного не делает. Кроме того современные процессоры весьма многоядерные и ещё более многопоточные, так что в 99% случаев ты просто задействуешь простаивающие ядра. Часто - вообще фоново, mglur срабатывает не просто заранее, а слишком сильно заранее!

А для десктопа — stress-ng рассудит.

Давай тесты, я только за! Но кстати, stress-ng это случайно не утилита на 300Кб памяти, гоняющая абсолютно пустые циклы? Т.е. максимально несвопящаяся штука, там просто нечего?

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Ну... я не впечатлён. Ты запросил 4 воркера выделяющего по 200% от 256М памяти если верить справке, но по факту в htop я вижу 206М на копию. При наличии 3,7 физической рамы это никак не мешает писать тебе ответ не дожидаясь завершения теста. Но надо признать пока воркеры создавались а вивальди вытеснялся - 3 секнды kwin висел.

До запуска

rrr@raspberrypi:/tmp $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        2306         480         214        1007        1232
Swap:          38145        2525       35620

в процессе работы

rrr@raspberrypi:/tmp $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        3178         107         209         508         372
Swap:          38145        3091       35054

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

пока воркеры создавались а вивальди вытеснялся - 3 секнды kwin висел.

Вот: создали давление, оно и задёргалось.

Но на 4 ГБ я бы тоже делал zswap, тут не поспоришь. С бо́льшим запасом, где swap бы простаивал, можно думать про обмен памяти на отклик.

anonymous
()
Ответ на: комментарий от anonymous

А вот 8 воркеров уже впечатлили! Система легла в трэшинг, usb2.0-ssd упёрся в свои 40 мб/с шины, вивальди вышел из чата, kwin, панелька и терминалы начали тормозить, хоть и сохранили работоспособность, и только курсор Х-сервера ничего не заметил. воркерам было выделено от 80 до 140М памяти а загрузка цпу держалась в районе 25%, остальное ожидание i/o.

В процессе теста:

rrr@raspberrypi:/tmp $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        3331          26         165         435         255
Swap:          38145        4464       33681

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

А что, не должно было? Разумеется процессы задёргаются когда их начнут стопорить, резать на части и упакоывать в своп. Память то и так переполнена на 100%. Но потом рабочие наборы стабилизировались и всё стало работать адекватно и даже без физического i/o.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Обнаружил странное поведение: с 1 воркером тормозов больше чем даже с 8.

Экспериментально обнаружено поведение опции --vm-bytes 200% как 200% о физической оперативки на все воркеры в сумме. Из за какого то непонятного распределения приоритетов 4 потока оказались оптимальнее всего для свопинга.

Странне зависимости у этой утилиты. По факту у меня система со всем запущенным хламом может оперировать только половиной в 1800М памяти, причём если поделить её на 4-8 процессов - то намного отзывчевей.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

В поддержку проверил на десктопе с 16 GB оперативки и swap на 2xNVMe:

  • запуск stress-ng с занятием 200 % свободной памяти с запущенным Firefox
  • время повторного запуска Firefox при стрессе после закрытия
  • степень сжатия

zswap в конфигурации zswap.max_pool_percent=50 zswap.compressor=zstd zswap.zpool=zsmalloc:

  • Запуск Firefox: min 3.2 s, max 4.5 s
  • Сжатие: stored_pages * 4096 / pool_total_size = 16.684
  • Субъективно: отклик c постоянной задержкой без проседаний

zram в конфигурации zram-size = 20480, compression-algorithm = zstd(level=1):

  • Запуск Firefox: min 2.5 s, max 5.1 s
  • Сжатие: orig_data_size / mem_used_total = 11.643
  • Субъективно: отклик без проседаний

Измерения безответственные, разница субъективна. Подумаю про возврат на zswap!

anonymous
()
Ответ на: комментарий от anonymous

И НАСКОЛЬКО lzo тут лучше zstd на смешанных данных!

Почему zstd пасанул на --vm-method all — ещё одна загадка.

for method in all flip zero-one; do
    for algo in lzo zstd; do
        sudo swapoff -a
        echo $algo | sudo tee /sys/module/zswap/parameters/compressor
        sudo swapon -a
        sync
        echo 3 | sudo tee /proc/sys/vm/drop_caches
        sleep 5
        echo "=== $algo method=$method ==="
        stress-ng --vm 4 --vm-bytes 200% --vm-method $method -t 15 --metrics-brief
        sleep 10
    done
done

lzo
3
=== lzo method=all ===
stress-ng: info:  [25120] setting to a 15 secs run per stressor
stress-ng: info:  [25120] dispatching hogs: 4 vm
stress-ng: info:  [25121] vm: using 4.91G per stressor instance (total 19.66G of 9.81G available memory)
stress-ng: metrc: [25120] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [25120]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [25120] vm               100651     15.33      5.29     55.80      6566.75        1647.61
stress-ng: info:  [25120] skipped: 0
stress-ng: info:  [25120] passed: 4: vm (4)
stress-ng: info:  [25120] failed: 0
stress-ng: info:  [25120] metrics untrustworthy: 0
stress-ng: info:  [25120] successful run completed in 15.61 secs

zstd
3
=== zstd method=all ===
stress-ng: info:  [25207] setting to a 15 secs run per stressor
stress-ng: info:  [25207] dispatching hogs: 4 vm
stress-ng: info:  [25208] vm: using 4.86G per stressor instance (total 19.43G of 9.70G available memory)
stress-ng: metrc: [25207] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [25207]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [25207] vm                    0     20.90      1.24     81.29         0.00           0.00
stress-ng: info:  [25207] skipped: 0
stress-ng: info:  [25207] passed: 4: vm (4)
stress-ng: info:  [25207] failed: 0
stress-ng: info:  [25207] metrics untrustworthy: 0
stress-ng: info:  [25207] successful run completed in 20.96 secs

lzo
3
=== lzo method=flip ===
stress-ng: info:  [25282] setting to a 15 secs run per stressor
stress-ng: info:  [25282] dispatching hogs: 4 vm
stress-ng: info:  [25283] vm: using 4.98G per stressor instance (total 19.90G of 9.94G available memory)
stress-ng: metrc: [25282] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [25282]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [25282] vm               732873     15.75      9.03     53.78     46535.87       11667.49
stress-ng: info:  [25282] skipped: 0
stress-ng: info:  [25282] passed: 4: vm (4)
stress-ng: info:  [25282] failed: 0
stress-ng: info:  [25282] metrics untrustworthy: 0
stress-ng: info:  [25282] successful run completed in 15.84 secs

zstd
3
=== zstd method=flip ===
stress-ng: info:  [25338] setting to a 15 secs run per stressor
stress-ng: info:  [25338] dispatching hogs: 4 vm
stress-ng: info:  [25339] vm: using 4.97G per stressor instance (total 19.87G of 9.92G available memory)
stress-ng: metrc: [25338] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [25338]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [25338] vm               545705     15.58      6.38     55.90     35025.17        8761.44
stress-ng: info:  [25338] skipped: 0
stress-ng: info:  [25338] passed: 4: vm (4)
stress-ng: info:  [25338] failed: 0
stress-ng: info:  [25338] metrics untrustworthy: 0
stress-ng: info:  [25338] successful run completed in 15.61 secs
anonymous
()