Каково соответствующее значение vm.swappiness при использовании zram?

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

Я действительно не рекомендовал бы поместить swappiness выше. Общий механизм в ядре - то, что оно поместит страницы (блок памяти) в подкачке для освобождения некоторой памяти для других выполняющихся задач.

Первая "проблема", когда ядро хочет, чтобы n страницы были освобождены, m (с m <n, m является числом сжатых страниц, требуемых содержать n) недавно создается в RAM, я не уверен, может ли это нарушить ядро или нет.

Затем так или иначе, когда у Вас есть страницы в подкачке, возможно, что Вы используете приложение позже с некоторыми его страницами в подкачке. То, что ядро делают, возвращают те страницы в физическую память, но не удаляет их из подкачки (который со стандартной подкачкой может рассматриваться как кэширование, поэтому когда приложение возвращается в фоновом режиме, ядро не должно записывать те страницы обратно в медленную подкачку). Однако с zram это - возможно, не мудрый прием, потому что у Вас затем есть в памяти m страницы в zram + n страницы, которые вернулись в памяти!

Ядро обычно имеет "общую память" thatit, может использовать для ведения ее бизнеса. Когда Вы добавляете zram, он рассчитывает в памяти "подкачки" только, как это было бы с любой находящейся на диске подкачкой, но он уменьшил фактическую "общую память", и это не ожидается/ожидается ядром. Иногда Вы можете иметь странный и не требуемое поведение из-за этого!

С zram было бы хорошо, что ядро не подкачивает слишком много к этой области, когда это испытывает давление памяти. И у Вас должен всегда быть очень твердый дисковый раздел подкачки, больше, по крайней мере, чем Ваш zram максимальный размер, так, чтобы система не получала OOM, тогда как одновременно Вы видели бы много свободного пространства, как сообщается free!

Короткий ответ :vm.swappiness=100: подходящее значение для zram (По крайней мере, в Debian Stretch с Linux 4.9, я считаю, что это лучшее значение)

Я уже тестирую vm.swappiness=100для себя.

Я думаю, вы можете провести простой тест , чтобы определить, какое значение лучше для вас.

Также я сделал другую простую программу для проверки этого вопроса. Икс На моей машине очень низкое vm.swappinessзначение (, такое как vm.swappiness=1), вызовет очевидную проблему с откликом.

О SwapCachedв/proc/meminfo:

Во-первых, попробуйте vm.page-cluster=0, это может уменьшить количество бесполезных SwapCachedсвопов -в

SwapCached может ускорить zram так же, как -устройство подкачки без zram

SwapCachedможно повторно использовать (бесплатно )при необходимости:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$