LINUX.ORG.RU

compcache принят в ядро Linux

 , , ,


0

1

В состав будущего ядра Linux 2.6.33 принято решение включить модуль compcache.
Модуль compcache реализует хранение раздела подкачки в сжатом виде в области ОЗУ. Таким образом большее количество данных можно хранить в оперативной памяти не использую раздел подкачки на жестком диске.
Автор compcache приводит пару примеров где такой подход может себя оправдать.
Нетбуки: в них объем ОЗУ ограничен, а мощности процессора хватит, чтобы пользоваться им с сжатой областью подкачки.
Виртуализация: используя compcache в гипервизоре, можно с легкостью прозрачно сжимать память, используемую в гостевом окружении в независимости от гостевой ОС (Linux, FreeBSD и т.д.). Это позволит запускать большее кол-во виртуальных машин.
Встроенные устройства: в таких устройствах памяти вечно не хватает и добавление дополнительной памяти приводит к увеличению стоимости устройства. Кроме того, флеш память изнашивается от частых операций чтения/записи. Поэтому полезно избежать ее использования в качестве раздела подкачки.
На данное число 16.12.2009 модуль уже включен в состав linux-next и находится в разделе Staging drivers.

>>> Подробности



Проверено: Shaman007 ()

> Это позволит запускать большее кол-во виртуальных машин.

OpenVZ-говнохостеры потирают руки и предвидят увеличение возможностей по оверселлингу.

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

>Есть 512 метров ОЗУ, под своп выделяем 384 Мб, итого можем получить (не мерил) около 500 Мб крайне быстрого свопа + 128 Мб остаётся обычной ОЗУ. Хорошая штука, правда её и так без всяких модулей можно реализовать.

неа, тока в файл в памяти, а сабж ещё одна серверная плюшка - не надо. Т.к. тот кому на самом деле нужно такое это, купит быстрые SSD диски и разместит радел подкачки на них.

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

> неа, тока в файл в памяти, а сабж ещё одна серверная плюшка - не надо. Т.к. тот кому на самом деле нужно такое это, купит быстрые SSD диски и разместит радел подкачки на них.

И при активном своппинге SSD накроются за пару месяцев?!

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

ОЗУ намного быстрее работает чем шуршание винтом или флеш памятью. Вспомните про UPX, сжатые им программы гораздо быстрее запускаются.

По теме: - фича очень нужная и полезная!

если ОЗУ дохрена, что не куда девать, то не проще ли отрубить своп вообще ?

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

неа, тока в файл в памяти, а сабж ещё одна серверная плюшка - не надо. Т.к. тот кому на самом деле нужно такое это, купит быстрые SSD диски и разместит радел подкачки на них.

Зачем SSD диски? Купить много ОЗУ =)

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

> И при активном своппинге SSD накроются за пару месяцев?!

Если долбить постоянно в одно и то же место флешки, то накроется и быстрее. Поэтому на SSD есть wear levelling.

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

> похожа на SuperFetch из висты

Ни капли не похоже. Superfetch - это предзагрузка софта.

а это больше на старый MagnaRAM из Qemm

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

> Неужели жертва Неандерталомора? (Я про аватару)

ананимус-хахол?

f00fc7c8
()

Прикольнее squashfs распологать в оперативной памяти.

linux4ever
()

И вновь Linux стал ближе к десктопу! Ура, товаришчи! Ура!

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

>Т.к. тот кому на самом деле нужно такое это, купит быстрые SSD диски...

Это что за мифические «быстрые SSD»? У SSD только позиционирование быстрое (в виду отсутствия) а линейная скорость существенно ниже чем у HDD. Спросите пользюков EeePC, они вам в красках расскажут.

По теме: Идея интересная, хотя практической ценности я пока не вижу. В эмбедах вообще никакого свопа никогда не делают, насколько мне это известно. Может если только хранить _всю_ ОЗУ в сжатом виде и распаковывать небольшими порциями по мере необходимости? Интересно, а с ростом производительности/уменьшением техпроцесса, скоро появятся планки памяти упаковывающие данные на лету? Ведь этож что начнется: «память Zip-DDR99 128-1024Tb» :)

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

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

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

> Возвращение QEMM!

Back to 90s!!!


Во-во, я тоже вспомнил.
Впрочем, штука полезная. На моей PDA-шке работает с Андроидом нормально ))

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

> нда, лучше не ходить по ссылкам и не ставить всякую гадость, раньше это работало нормально, а теперь сделали поддержку backing swap, т.е. свап на диск через ramzswap, включила... весь раздел с / в хлам..

Блин, мне даже тебя жалко стало. Надеюсь, у тебя, как у истиного красноглазика, всё (/home, /boot, /usr, /var) на отдельных разделах и / занимает метров 300, что не составит труда обновить.

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

>Кстати, разве линукс кернел подефолту не начинает свопить только когда ОЗУ совсем уж не хватает ?
вовсе нет. состояние когда в системе 50Гб используется под файловый кэш и при этом свап юзается очень активно - нередкое явление.

prizident ★★★★★
()

Что-то я не догоняю - в нетбуках ОЗУ маленькое, так давайте swap полностью в ОЗУ сунем. Где логика?

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

> Что-то я не догоняю - в нетбуках ОЗУ маленькое, так давайте swap полностью в ОЗУ сунем. Где логика?

Логика в том, что часть содержимого оперативки (иногда довольно большую) можно скинуть в подкачку. Так вот чтобы это было быстрее - придумали сабж.

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

> Спросите пользюков EeePC, они вам в красках расскажут.

Что тебе рассказать? То, что у нормальным пользователей стоит быстрая и дорогая NOR-флеш, а у пользователей eeepc-90x наряду с ней ещё и медленная (дешёвая) NAND-флеш, которой напихано много гигабайт. Это рассказать? Не грузи людей, коль не знаешь сути.

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

не скажу насчет /var и /usr, но /home и /boot на раздел отдельный выносить крайне желательно. В случае с первым вы отделяете свои данные от системных и ими удобнее оперировать, а в случае со вторым вы позволяете себе на корне в качестве ФС использовать что душе угодно, а не только то, что держит загрузчик (делаете /boot на 50 метров ext2).

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

> Возвращение QEMM!

Back to 90s!!!

Апередил! Только собирался проехаться насчет технологий прошлого века. :)

faustus
()

Интересно, а вот просто прослойка для создания сжатого блочного устройства поверх любого блочного - бывают? А то мне вспомнились системы позволяющие набор модулей памяти представить, как блочное устройство. :) Я погуглил, что-то под названием CBD нашлось, но совершенно не понятно где хомпейдж, кто разрабатывает и т.д.

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

> Логика в том, что часть содержимого оперативки (иногда довольно большую) можно скинуть в подкачку. Так вот чтобы это было быстрее - придумали сабж.

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

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

> в случае со вторым вы позволяете себе на корне в качестве ФС использовать что душе угодно, а не только то, что держит загрузчик (делаете /boot на 50 метров ext2).

У нормальных людей загрузчик не привязан к типу ФС и умеет грузиться с любой, даже экзотической.

anonymous
()

Новость перевернула взгляды на жизнь. Решение лежало на поверхности. Очень хорошая идея. Такая возможность понадобится многим. Винт намного медленнее !

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

> У нормальных людей загрузчик не привязан к типу ФС и умеет грузиться с любой, даже экзотической.

Мне просто интересно, а как это? Загрузчик должен знать как обращаться с партицией с которой ему нужно загрузить ядро (по крайней мере как на этой партиции найти то самое ядро). Для этого он сам должен повторять функциональность ядра по части работы с файловыми системами. Неужто в него впихивают все файловые системы известные человечеству? И какой загрузчик это умеет?

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

Наверно вы имеет в виду LILO. Но и там есть свои косяки (например с необходимостью перепрошивки при изменении конфигурации).

EvilBlueBeaver
()

zfs плохо, потому что zfs и хочет много памяти

compcache хорошо, потому что линукс (и хочет много памяти)

Продолжайте в том же духе.

P.S. А ReactOS в kernel - вот лично мне нравится идея) Стройно будет.

jSnake
()

В состав будущего ядра Linux 2.6.33 принято решение включить модуль compcache.
Модуль compcache реализует хранение раздела подкачки в сжатом виде в области ОЗУ. Таким образом большее количество данных можно хранить в оперативной памяти не использую раздел подкачки на жестком диске.

прриятная новость. жаль что топикпастер не написал какой алгоритм сжатия используется.

По теме: если посмотреть сколько занимает сжатый hibernate-образ, то можно увидеть что в среднем он жмется в 2-2.5 раза. То есть каждый байт выделенный в такой раздел подкачки дает примерно (в среднем) 2-2.5 байт к общей виртуальной памяти.

Таким образом скажем ноутбук с 1024M памяти с выделением 512 в такой своп будет эквивалентен ноуту с 1500М памяти.

а ноут с 4G будет эквивалентен ноуту с 1 + 3 * 2 = 7G. Это уже совсем приятно :)

если учесть что в нынешних десктопах CPU обычно загружен слабо, то получается память-то почти бесплатная.

какой алгоритм сжатия там используется? lzo?

rsync ★★
()

Давным давно видел в новостях что такой штучкой баовался NEС...

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

Вот и размещайте файл подкачки в виртуальной памяти как тут отжигал один шпециалист. А насчёт сжатия памяти, ничего так, нормально, только направление не должно быть ограничено. Хотим часть ОЗУ отдать под сжатие - пожалуйста, хотим раздел или файл - тоже милости просим. Хотя немного не понятно как они COW могут улучшить. Память и так типа сжата. Типа std::share_ptr<>. Интересен эффект. Так сказать в процентах.

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

При таком проце такой децил памяти?... А поставить одну двухгиговую планку религия не позволяет?

P.S. Я поставил 8 гиг не для понту а с рассчетом на будующее.

keeper-andrew
()
Ответ на: комментарий от rsync

Если hybernate по своей тупости сохраняет не только используемую память, а всю ОЗУ, то удивительно что не в 10 раз (в зависимости от ситуации).

alx_me ★★☆
()
Ответ на: комментарий от keeper-andrew

Гопник? Ну вам можно не знать, что любая материнская плата имеет ограничение на объём памяти в слоте.

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

> Если hybernate по своей тупости сохраняет не только используемую память, а всю ОЗУ, то удивительно что не в 10 раз (в зависимости от ситуации).

а в линуксе классически используется вся память. под кеши.

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

Я вам ещё один способ сжатия hybernate подскажу, хотите? Поставьте патчик от selinux для обнуления освобождаемой памяти. Точно вам говорю сожмётся в 10 раз.

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

> Ага и вот именно эти кэши очень важно созранить в файле hybernate. Так?

по моему ничего плохого от их сохранения не будет: по возвращении из хибернате, пользователь скорее всего продолжит работу => кеши для него будут вполне актуальны.

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

>А почему не сжимать данные на прям в разделе подкачки?

Скорость доступа к разделу подкачки и к области памяти «слегка» различается.

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

MagnaRAM

It is a memory compression utility for Windows 3.1, Windows For Workgroups, Windows 95. MagnaRAM is included with QEMM 97.

MagnaRAM was also released as a separate utility.[1]

MagnaRAM worked by replacing a portion of Windows' virtual memory system. MagnaRAM would insert itself in the string of Windows Programs that determined what pieces of RAM will be moved to the hard disk. Instead of writing directly to the hard disk, the information to be written would go to MagnaRAM's own buffer as this was a faster process. During CPU idle, MagnaRAM would compress the information in its own RAM buffer. When the RAM buffer becomes full, it is then swapped to the hard disk taking both less time and less space.[2]

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

А когда это SSD стали быстрыми? Быстрыми не в смысле быстрее ноутбучных недодисков 2,5" и 4200 rpm а хотя бы соизмеримыми с SAS

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

реально у меня только побился портеж живущий в /lib/portage
init (своевременно выдал сегфолт и спас остальные данные в разделе)
dhcp
udev

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


либо этот компкэш пытается воспринять файл как раздел, либо он ничего не знает про то что файл все таки может быть фрагментирован
включала вот так ( /vmswap - свап файл )
#modprobe ramzswap
#/usr/local/sbin/rzscontrol /dev/ramzswap0 -i -b /vmswap
#swapon /dev/ramzswap0

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

>Интересно, а с ростом производительности/уменьшением техпроцесса, скоро появятся планки памяти упаковывающие данные на лету

Мне странно что они до сих пор не появились. Ничего страшного в том же lzo нет да и в виртуальная адресация вре равно уже давно. Нужен будет только патчик на ось страхующий от переполнения/недозаполнения (ибо заранее неизвестно сколько памяти таки свободно)

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

Гиг флеш-памяти стоит примерно столько же сколько гиг оперативки, но озу работает гораздо быстрее. Так что смысла в SSD под подкачку практического нет, тем более на серверах а не на бюджетных микро-АТХ с 2мя слотами под мозги

DNA_Seq ★★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.