Comments 99
Самое главное что девушка довольна)))
Все же непонятно, как оно работает… Откусывается кусок оперативной памяти, или это прозрачно для других приложений.
Насколько быстрей стал работать компьютер у девушки?
Насколько быстрей стал работать компьютер у девушки?
Работает примерно также как tmpfs — откусывает кусок памяти «от имени ядра».
Из интересных подробностей: команды discard\trim это блочное устройство воспринимает примерно также как ssd. Под капотом высвобождаются используемые блоки памяти.
Потому если на блочном устройстве сделать файловую систему не умеющую discard\trim, то освобождаться эта память почти не будет(но вырасти неограниченно она не может, так как вы задали максимальный размер несжатых данных).
Из интересных подробностей: команды discard\trim это блочное устройство воспринимает примерно также как ssd. Под капотом высвобождаются используемые блоки памяти.
Потому если на блочном устройстве сделать файловую систему не умеющую discard\trim, то освобождаться эта память почти не будет(но вырасти неограниченно она не может, так как вы задали максимальный размер несжатых данных).
И наивный вопрос, есть ли аналог под винду?
Невозможно в силу технических особенностей ядра Windows.
Можно подробней? Интересно очень)
Если Вы посмотрите материал на тему менеджера памяти Windows то заметите что MS не оставила релоков или хуков на случаи расширения памяти в процессе, в Linux и UNIX в этом плане проще и есть вариант расширения памяти на лету.
Если посмотреть исходники ReactOSкоторые были получены реверсом то примерно понять работу стандартного менеджера можно.
Хотя конечно в принципе возможен порт модуля zRAM — но только для обычных приложений (ring3 level) — это писать драйвер для хука Win32 API по работе с памятью — например VirualAlloc, HeapAlloc и т.д. — и управлять таким образом памятью. Ну конечно не забыв при этом пофиксить пачку системных DLL и SxS — т.к. некоторые программы не будут работать нормально при хуке импорта в процессе.
Если посмотреть исходники ReactOS
Хотя конечно в принципе возможен порт модуля zRAM — но только для обычных приложений (ring3 level) — это писать драйвер для хука Win32 API по работе с памятью — например VirualAlloc, HeapAlloc и т.д. — и управлять таким образом памятью. Ну конечно не забыв при этом пофиксить пачку системных DLL и SxS — т.к. некоторые программы не будут работать нормально при хуке импорта в процессе.
А что мешает создать сжатый RAM-диск? Конечно, могут быть трудности с размещением в нем файла подкачки (диск должен создаваться раньше, чем файл подкачки во время загрузки), но замапить туда тот же TEMP или еще что вполне реально… Или вы о чем-то другом?
/me задумался о более эффективном использовании своих 16 гигов оперативы..
/me задумался о более эффективном использовании своих 16 гигов оперативы..
Можно, но можем получить цикличный эффект, т.е. когда страницы буду очень часто обмениваться и в целом это будет не очень хорошо.
По поводу диска, насколько Я помню был вариант загрузки драйвера ДО старта подкачки, правда не могу точно сказать за новые ядра от Win7/8.
/me у меня 32GB и больше, однако продакшен софт все-равно лучше тестить на продакшен железе, т.к. дома такое достаточно проблематично собрать и поставить.
По поводу диска, насколько Я помню был вариант загрузки драйвера ДО старта подкачки, правда не могу точно сказать за новые ядра от Win7/8.
/me у меня 32GB и больше, однако продакшен софт все-равно лучше тестить на продакшен железе, т.к. дома такое достаточно проблематично собрать и поставить.
А как же тогда девушка довольна?
Пользовался подобным под windows 95. Оно умело сжимать данные в ОЗУ и при этом виндовс показывал не 4М RAM, а 7М.
Название может быть qmem, но могу ошибаться.
Название может быть qmem, но могу ошибаться.
Быть может, QEMM?
Можно еще так.
Начиная с Windows 10 работает из коробки
Изменения в скорости работы у девушки пока firefox не сьел всю память незаметны.
После того как сьел — до этого был мягко говоря черепахой, работать было невозможно. После изменения — в реальный swap мало что уходит вообще, вероятно память используемая firefox легко сжимается.
После того как сьел — до этого был мягко говоря черепахой, работать было невозможно. После изменения — в реальный swap мало что уходит вообще, вероятно память используемая firefox легко сжимается.
Получается два своп-файла, один на блочном устройстве другой на реальном хдд? А по какому принципу они приоритезируются?
Параметр -p который я передавал в
В итоге: если у swap на диске приоритет по умолчанию и для zram указан приоритет 10, то swapping на диск не будет происходить до израсходования размера zram.
swapon /dev/zram0 -p 10 это и есть приоритет. Страницы подкачки располагаются в устройствах и файлах подкачки согласно убыванию их приоритета(сначала полностью заполняются пространства с большим приоритетом). Приоритет по умолчанию — 1.В итоге: если у swap на диске приоритет по умолчанию и для zram указан приоритет 10, то swapping на диск не будет происходить до израсходования размера zram.
>Все же непонятно, как оно работает
судя по тексту статьи, грубо говоря — своп сначала делается на виртуальный диск и только если его не хватает — то на реальный винт.
Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
судя по тексту статьи, грубо говоря — своп сначала делается на виртуальный диск и только если его не хватает — то на реальный винт.
Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
UFO just landed and posted this here
А сжимать данные в обычном свопе на венике нельзя?
Скорость жёсткого диска всё равно значительно медленнее. А здесь получается производительность почти как у памяти, с небольшим оверхедом на сжатие.
так в статье речь про скорость или увеличение объёма памяти?
См. мой комментарий:
Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
См. мой комментарий:
Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
Как не понятно-то: в хорошем случае те страницы, которые свопнуты в память таким образом, сжимаются в 2-3 раза при этом почти не теряется скорость работы с ними. Следовательно, это в первом приближении то же самое, что и увеличение доступной памяти.
мне трудно представить, что данные, которые сбрасываются в своп и при этом ещё и сжимаются/разжимаются дают такое же время доступа как и «обычные», какую бы магию тут не пророчил описанный рецепт. Имхо, сравнивать нужно не с системой «только RAM» а с системой «RAM+swap». И по сравнению с ней данный рецепт даёт только прирост скорости, причём его ещё нужно правильно подсчитать, т.к. «ускоренный своп» делается в ущерб объёму «нормальной» (по скорости) памяти.
В случае, когда памяти хватает на всё: во всех случаях (нет свопа, zRAM, дисковый своп) все данные размещаются непосредственно в памяти и скорость одинакова.
Когда память заканчивается: в случае zRAM часть памяти отводится под сжатые страницы (соответственно, туда помещается больше страниц, чем при обычном свопе), откуда они достаются быстрее, чем с диска => скорость больше.
Ну а когда не хватает и zRAM, тогда в любом случае нужно обращаться к диску, что очень медленно.
Таким образом, производительность с zRAM всегда не хуже чем в других вариантах (по крайней мере, в теории — на практике нужно проводить тесты).
Когда память заканчивается: в случае zRAM часть памяти отводится под сжатые страницы (соответственно, туда помещается больше страниц, чем при обычном свопе), откуда они достаются быстрее, чем с диска => скорость больше.
Ну а когда не хватает и zRAM, тогда в любом случае нужно обращаться к диску, что очень медленно.
Таким образом, производительность с zRAM всегда не хуже чем в других вариантах (по крайней мере, в теории — на практике нужно проводить тесты).
Насколько я понимаю, происходить сжатие данных для хранения в памяти. При этом создается обычное блочное устройство. Если сделать своп на zRam, он, естественно, будет работать быстрее чем своп на винт, т.к. сжатие в память работает быстрее чем сброс данных на винт.
Правда, не совсем понятен механизм выигрыша при использовании именно свопа. Ведь сама система zRam отъедает кусок ОЗУ.
Правда, не совсем понятен механизм выигрыша при использовании именно свопа. Ведь сама система zRam отъедает кусок ОЗУ.
Да, zRam отьедает кусок ОЗУ. Но она не хранит полностью нулевые страницы памяти, и те данные которые она хранит почти всегда в сжатом виде занимают меньше места чем оригинальные.
Моя практика показывает что на сервере виртуализации степень сжатия 1 к 3. На ноутбуке девушки видел и 1 к 10.
Моя практика показывает что на сервере виртуализации степень сжатия 1 к 3. На ноутбуке девушки видел и 1 к 10.
Ну, тогда, в общем-то имеет смысл. Надо будет попробовать. Еще-бы, конечно, неплохо было разместить информацию о доступности этого модуля в разных версиях ядра.
Интересно, почему ОС не делает такую оптимизацию изначально?
OC делает такую оптимизацию на момент выделения страницы. Для нормальных страниц, если мне не изменяет память, такая оптимизация есть очень давно.
Для huge-pages появилась в 3.8.
zRam делает это не в момент выделения, а в процессе работы. Часто бывает что какието данные в странице «были, да сплыли». То есть после того как OC выделила страницу с нулями, какое то значение было записано, а потом обнулено. В итоге страница полна нулей, но чтобы ОС сделала оптимизацию нужны какие то трюки.
Для huge-pages появилась в 3.8.
zRam делает это не в момент выделения, а в процессе работы. Часто бывает что какието данные в странице «были, да сплыли». То есть после того как OC выделила страницу с нулями, какое то значение было записано, а потом обнулено. В итоге страница полна нулей, но чтобы ОС сделала оптимизацию нужны какие то трюки.
Сделал бы кто-нибудь обзор всяких прикольных, неизвестных и полезных модулей ядра
Ядро слишком разнообразно и многие фичи нужны очень ограниченному кругу лиц. Многие спорны и холиварны(тотже x32 ABI)
Если Вы укажете какие для Вас представляют интерес — может опишу.
Если Вы укажете какие для Вас представляют интерес — может опишу.
Огласите весь список, пжалста… Или раскажите где/как вы их находите? На kernel.org, на git.kernel.org? С ходу не обнаружил…
Как нахожу:
Я гентушник. Причем не потому что скомпилированная система под локальную машину имеет некое ускорение. И не потому что скомпилированная под мои нужны включает только то что мне надо и весит 3 гига. А потому что я получаю наслаждение от понимания что, как и почему работает.
Во время компиляции очередной версии ядра, иногда вчитываюсь в настройки, начинаю гуглить и разбираться. И нахожу такие плюшки.
Во время появления новых приложений в дереве portage читаю их описания. Если заинтересовало — гуглю. Вскоре собираюсь написать статью о opensource full-mesh vpn сети. О которой узнал потому что у нее полтора месяца назад появилась новая версия в portage.
Я гентушник. Причем не потому что скомпилированная система под локальную машину имеет некое ускорение. И не потому что скомпилированная под мои нужны включает только то что мне надо и весит 3 гига. А потому что я получаю наслаждение от понимания что, как и почему работает.
Во время компиляции очередной версии ядра, иногда вчитываюсь в настройки, начинаю гуглить и разбираться. И нахожу такие плюшки.
Во время появления новых приложений в дереве portage читаю их описания. Если заинтересовало — гуглю. Вскоре собираюсь написать статью о opensource full-mesh vpn сети. О которой узнал потому что у нее полтора месяца назад появилась новая версия в portage.
Поделитесь конкретным конфигом для нетбука, у меня как раз машинка с двумя гигами есть
На нетбуке у девушки стоит gentoo(вообщето Calculate, но это gentoo :) )
zRam вкомпилирован в ядро. При загрузке ядру передается
Из них используются только 2, с размерами по 768мег(в итоге 3/4 памяти может быть сжато)
созданы файлы
/etc/local.d/zram.start
/etc/local.d/zram.stop
/tmp вынесен в tmpfs, с ограничением размера на 1 гиг.
zRam вкомпилирован в ядро. При загрузке ядру передается
zram.num_devices=4 Из них используются только 2, с размерами по 768мег(в итоге 3/4 памяти может быть сжато)
созданы файлы
/etc/local.d/zram.start
#!/bin/bash
#modprobe zram num_devices=4
SIZE=768
echo $(($SIZE*1024*1024)) > /sys/block/zram0/disksize
echo $(($SIZE*1024*1024)) > /sys/block/zram1/disksize
mkswap /dev/zram0
mkswap /dev/zram1
swapon /dev/zram0 -p 10
swapon /dev/zram1 -p 10
/etc/local.d/zram.stop
#!/bin/bash
swapoff /dev/zram0
swapoff /dev/zram1
echo 1 > /sys/block/zram0/reset
echo 1 > /sys/block/zram1/reset
/tmp вынесен в tmpfs, с ограничением размера на 1 гиг.
Через udev элегантней и правильнее создавать устройства.
rules.d # cat 10-zram-swap.rules
KERNEL==«zram0», ACTION==«add», ATTR{disksize}=«2097152000», RUN="/sbin/mkswap /$root/$name"
а приоритет можно выставлять при монтировании в /etc/fstab
rules.d # cat 10-zram-swap.rules
KERNEL==«zram0», ACTION==«add», ATTR{disksize}=«2097152000», RUN="/sbin/mkswap /$root/$name"
а приоритет можно выставлять при монтировании в /etc/fstab
Главное не спутать Атом с двумя ядрами и Атом с гипертредингом.
Если сделать два девайса на гипертрединге, то цпу будет полностью занят системой, а когда свопы в памяти закончатся — всё встанет.
С одним девайсом фурычит нормально, наконец-то можно отдаться пороку открытия бесконечных вкладок в браузере и запуска Eclipse на нетбуке =)
Если сделать два девайса на гипертрединге, то цпу будет полностью занят системой, а когда свопы в памяти закончатся — всё встанет.
С одним девайсом фурычит нормально, наконец-то можно отдаться пороку открытия бесконечных вкладок в браузере и запуска Eclipse на нетбуке =)
В результате гуглежки наткнулся вот на это. Если точнее, init.d скрипт вот тут лежит (или посмотреть на гитхабе). Если будете ставить на Debian Wheezy, то в скрипте нужно поменять на 26 строчке «modprobe zram num_devices=..» на «modprobe zram zram_num_devices=..», это бага, посмотреть багу можно тут.
Объясните пожалуйста как происходит прозрачное сжатие памяти виртуальных машин. Из статьи понятно только как swap там настроить.
Для host-системы память виртуальных машин это память приложений.
Когда физической памяти будет недостаточно для хранения памяти всех приложений, ядро начинает swapping редко используемых страниц памяти. Причем это происходит для памяти, как занятых приложениями, так и tmpfs. В итоге редко используемая память виртуальных машин будет сжата.
Когда физической памяти будет недостаточно для хранения памяти всех приложений, ядро начинает swapping редко используемых страниц памяти. Причем это происходит для памяти, как занятых приложениями, так и tmpfs. В итоге редко используемая память виртуальных машин будет сжата.
поделись конфигом сервера виртуализации? и что на нам, xen?
Kvm. На нем поставлен gui — app-emulation/virt-manager. Сеть и жесткие диски по virtio, графика по spice.
Никаких конфигов руками не правлено, все по-умолчанию.
Если вызывать из консоли это будет чтото вроде
Никаких конфигов руками не правлено, все по-умолчанию.
Если вызывать из консоли это будет чтото вроде
qemu-kvm -m 2048 -name xp-ie8 -drive file=/srv/images/Xp-ie8.img,if=virtio -vga qxl -spice port=5900,addr=127.0.0.1,disable-ticketing -net nic,macaddr=00:1e:3e:00:00:14,model=virtio -net tap,ifname=tap04
Интересен еще KSM/uKSM, есть опыт использования?
KSM у меня включен уже давно. С добавления его в mainline в 2.6.32. И сравнивать уже тяжело. Он не дает ощутимого замедления и порой дает уменьшение размера. Вещь безусловно полезная.
uKSM не использую и не буду до того как не войдет в mainline, так как желание попадаться на «локальные особенности» у меня уже иссякло. Наигрался.
uKSM не использую и не буду до того как не войдет в mainline, так как желание попадаться на «локальные особенности» у меня уже иссякло. Наигрался.
Интересно на Android такое используется? И какой выигрыш может дать? :)
Пытался пользоваться этой штукой года три-четыре, а потом еще раз ~два, назад, и она была так себе стабильна — при сильной нагрузке можно было схлопотать странное. Уж не знаю, правда, почему — не доходили руки разбираться.
Из интересных вариантов расположения свопа есть еще видеопамять.
Из интересных вариантов расположения свопа есть еще видеопамять.
Какой алгоритм используется для сжатия? Если gzip, то слишком медленно. Если LZO, то стоит попробовать.
Как мониторить, сколько памяти занимают данные в памяти? /sys/block/zram0/size — оно?
Как мониторить, сколько отжирается CPU на [де]компрессию?
Как мониторить, сколько памяти занимают данные в памяти? /sys/block/zram0/size — оно?
Как мониторить, сколько отжирается CPU на [де]компрессию?
С мониторингом CPU стоит как-то относится осторожно. По идее, каждый раз, когда будет обращение к такому swap, будет происходить context switch на task, который вынет и распакует страницу памяти. Тут не на проценты стоит смотреть, а тестить в каждом отдельном случае. Для некоторых приложений csw не так страшен, а для некоторых критичен.
Алгоритм, насколько мне известно LZO. Но были и патчи для snappy, однако приняты не были.
у меня
Есть
Есть
Есть
Есть
В итоге для расчета степени сжатия я использую формулу
Как адекватно измерить потребление CPU на сжатие данных ядром я не знаю. Если Вы знаете метод — буду рад протестировать.
Как мониторить, сколько памяти занимают данные в памяти? /sys/block/zram0/size — оно?
у меня
size там отсутствует.Есть
zero_pages — количество страниц заполненных нулями.Есть
orig_data_size — размер изначальных данных за вычетом «нулевых» страницЕсть
compr_data_size — размер данных в сжатом виде.Есть
mem_used_total — суммарное потребление памяти с учетом фрагментации и метаданных.В итоге для расчета степени сжатия я использую формулу
mem_used_total/(zero_pages*4096+orig_data_size)Как адекватно измерить потребление CPU на сжатие данных ядром я не знаю. Если Вы знаете метод — буду рад протестировать.
Где были мои глаза?!
Однако, судя по www.kernel.org/doc/Documentation/ABI/testing/sysfs-block-zram
zero_pages*4096 из вашей формулы нужно исключить.
Однако, судя по www.kernel.org/doc/Documentation/ABI/testing/sysfs-block-zram
zero_pages*4096 из вашей формулы нужно исключить.
При написании ответа я пользовался этим же файлом
Количество страниц. Стандартный размер страницы для x64 — 4Кбайт. Потому чтоб получить размер изначальных нулевых страниц в байтах
The zero_pages file specifies number of zero filled pagesКоличество страниц. Стандартный размер страницы для x64 — 4Кбайт. Потому чтоб получить размер изначальных нулевых страниц в байтах
zero_pages*4096Итогам использования и размышлений в течение нескольких дней
- Не уверен в оптимальности создания zram блочных устройств по количеству ядер. Это делается в надежде, что на каждый чих будут задействованы все ядра, т.е. на всех произойдёт context switch. При этом при тяжёлой нагрузке на zram основными операциями будут извлечения сжатых страниц, что и на одном ядре должно происходить достаточно быстро. Нужны бенчмарки. Который всё равно мало что докажут, т.к. на разных нагрузках и процессорах оптимальные стратегии могут отличаться
- При освобождении страниц в свопе zram не идеально освобождает занятую память, compr_data_size/mem_used_total легко опускается до 0.8. Из общих соображений, при использовании только одного zram блочного устройства эффективность использования памяти должна быть выше. Я на всех своих машинах использую
num_devices=1 - Опять-таки из общих соображений на x86_64 эффективность сжатия должна быть значительно выше, чем на i686, т.к. из-за увеличения interger'ов и различного выравнивания структур в памяти на архитектуре x86_64 будет гораздо больше нулей. Моя небольшая нерепрезентативная статистика это подтверждает: на i686 десктопе
compr_data_size/orig_data_sizeколеблется в интервале 0.45 — 0.6, а на x86_64 крутится в интервале 0.3 — 0.35 - На большинстве моих машин количество занятого места в свопе согласно /proc/swaps совпадает с
mem_used_total+zero_pages*4096. А вот на убунточке вечно всё не как у людей
$ uname -a Linux olga-notebook 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ head /sys/block/zram0/{orig_data_size,zero_pages} ==> /sys/block/zram0/orig_data_size <== 101617664 ==> /sys/block/zram0/zero_pages <== 1505 $ awk '/zram/{print $4}' /proc/swaps 139624 $ echo $(( (101617664+1505*4096)/1024 )) 105256
А где ~34 неучтённых мегабайта?! Я было подумал, что из-за того что zero_pages включили в себя transparent huge pages, но нет
$ grep AnonHugePages /proc/meminfo AnonHugePages: 12288 kB
Идея хорошая, но ещё есть потенциал для развития, ведь если прикрутить сжатие нативно к пейджеру — получится ещё производительнее. Сейчас ядро вынуждено гонять страницы через I/O систему к zram и обратно, когда в этом нет необходимости.
Ещё одна идея для улучшения — несжимаемые и слабосжимаемые страницы (а таковы тоже найдутся, например jpg или другой медиаконтент) принудительно сбрасывать таки на дисковый своп. И опять же нативная поддержка пейджером будет куда предпочтительней, т.к. для zram придется делать файловый бакенд на диске, а использовать fs для свопирования не самая лучшая идея — не зря в unix-ах swap лежит в отдельном блочном устройстве.
Не пойму, как Рыжелиса разогнать удалось? Из-за того, что своп переехал в сжатую память, и стал быстрее? Так Лис жрет ОЗУ столько, что на 2 Гб он да ОС и влезут, т.е. отдать заметный объем под swap вроде как нереально…
Для убунты достаточно выполнить
sudo apt-get install zram-config
:)
sudo apt-get install zram-config
:)
Поясните пожалуйста, а в чём отличие от просто выключенного свопа? Кроме сжатия данных. Зачем свопить, если можно держать всё в озу?
Зачем свопить, если можно держать всё в озу?
Пока все влазит в ОЗУ и тут тоже не будет свопа.
Поясните пожалуйста, а в чём отличие от просто выключенного свопа?
В поведении когда ОЗУ кончается. Отключенный своп череват
oom-killer-ом. Например: на серверах виртуалок, плотность укладки виртуалок часто превосходит доступное количество памяти, потому swap выключать нельзя. А латентность сжатия на порядки ниже чем время доступа к жесткому диску. Даже ssd.
Пока влазит — не будет, но кусок ОЗУ то уже будет скушан, а так понял это актуально только для виртуалок или где-нить ещё, где ОЗУ может кончиться?
Например для Raspberry Pi
Если виртуалки однотипные, то модуль который объединяет страницы памяти с одинаковым содержимым (забыл, как он называется) должен помочь намного больше, чем zram.
<irony>
— Слушай, Гена, давай я понесу чемоданы, а ты понесёшь меня…
— Это ты здорово придумал, Чебурашка!
</irony>
— Слушай, Гена, давай я понесу чемоданы, а ты понесёшь меня…
— Это ты здорово придумал, Чебурашка!
</irony>
UFO just landed and posted this here
Для тех, кто задается этим вопросом: гибернация работает, суспенд в память работает.
Почему-то в статье к команде swapon не добавлена опция -d, которая заставляет ядро делать discard на блоки swap'а, которые не нужны. Без этой опции, если система попользуется swap'ом и потом посчитает, что больше ей там хранить нечего, сжатые страницы ей не вернутся.
UFO just landed and posted this here
А есть ли опыт использования подобного в продакшне?
Я ж правильно понимаю, что для 32битной системы объем памяти плюс свопа не должен превышать 4 Гб?
«Оно больше внутри, чем снаружи!» (с)
Насколько я понял, каждое ядро распаковывает страницу для себя само.
Но вот интересно, а если одно из (4-х) ядер сделать dedicated упаковщиком/распаковщиком — получится в среднем быстрее или нет?
Насколько я понял, каждое ядро распаковывает страницу для себя само.
Но вот интересно, а если одно из (4-х) ядер сделать dedicated упаковщиком/распаковщиком — получится в среднем быстрее или нет?
А как правильнее сделать монтирование при старте системы?
с ядра 3.11 и обычный swap начнёт поддерживать прозрачное сжатие.
сжатие каждого устройства zram однопоточное
Это уже давно не так, вроде бы.
К областям применения можно добавить ещё мобильные телефоны на Андроиде. Даже производители зачастую включают zswap, ну а с рутом можно выиграть х1.5 а то и х2 от оперативки.
Sign up to leave a comment.
Использование zRam для увеличения количества доступной памяти под Linux