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

что-то здесь не так... ^_^

если нужен быстрый свап, ну, может какая-то софтина требует, можно создать rаm-диск, оформить его как свап и подключить. опять же, может это будет лучше, чем вырубать свап из ядра. а сабж какой-то подозрительный...

А vfs c жатием чем уже не угодил для данных ?

ram-disk вроде сжатие не поддерживает. tmpfs точно. Так что выигрыша не будет.

А вообще да, нужно сего модуля под вопросом. И если уж нужно то, наверное, действительно легче было бы добавить сжатие к tmpfs.

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

Очнись, запись во флеш-память всегда сопровождается предварительным стиранием, причем блок составляет, как правило, 64к. И потом, вьюноша, «быстрая и дорогая» это не NOR и не NAND. NOR - дорогая, NAND - быстрая. Если вздумал спросить «нахрена тогда нужна NOR?», подскажу: NOR - это флешка с биосом, стоит в каждой материнке.

> Не спорю, но топик про сжатие чего-то там? Вот я в тему и ляпаю.

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

dd if=/dev/sda2 |lzop|wc -c

512775733

то есть раздел подкачки который имел размер 2Gb сжало до размера 489Мб. то есть в 4 раза. это живая машинка, с которой я сейчас пишу. аптайм чуть больше двух месяцев. постоянно запущены Xorg, firefox и прочий клиентский софт. На машинке RAM 2G, SWAP 2G. Можно выключить SWAP, выделить compcache 512М и получится 1.5 + 2 = 3.5G - почтишто полный эквивалент.

подождем конечно ядра 33, но мне кажется это очень полезная фича

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

Да, LZO. Модуль в ядре даже есть такой (давно уже, вот он и используется).

Не ,NOR и быстрая, дорогая и надежная - но, не для ширпотреба.
Применяется в основном как память программ. (линейная или последовательная).
NAND - дешёвая и менее надежная чем NOR и довольно часто менее скоростная.

Простите за необознаность, но название пошло от логических функций NOR и NAND? Если да, то чем стрелочка Пирса быстрее штриха Шеффера? Обе эквивалентно заменимы в комбинационных схемах по определенным правилам.

Ну тогда +1

Я выше так шутил. :-D. Да начитанность местных аналитиков неизменно доставляет. Идея с tmpfs не проходит по той причине, что swap необходимо вынести из области ОЗУ для которой в protected mode резервируются exceptions для page-ов. Дабы не убить ядро рекурсивными выбросами оных. Коий вывод ясно следует из механизма виртуальной памяти x86. Кстати о птичках. А как у сего патча с переносимостью?

> то чем стрелочка Пирса быстрее штриха Шеффера

Вся разница в технологиях
NOR - впервые появился у Intel
NAND - у Amd (вроде так)

Вообще один получился на листочке бумаги у Шеффера, другой у Пирса.

Обе функции являются монофункциональными базисами. Это означает что если бы имеем неограниченое количество к примеру NAND (которые элементарно собирается с резисторов и транзисторов), то можем реализовать любую булевую функцию. Отсюда можем реализовать любую комбинационную схему, так как функция и схема эквивалентны. Любая КС => триггер, дешифратор, мультиплексор и т.д. На триггерах строим регистр. Регистры можно программировать на выполнение любых операций. Причем операций по коду команды. Собираем кучу регистров, которые поддерживают микрооперации => процессор. Потом собираем еще более большую кучу, ставим мультиплексор к ним => ОЗУ. Процессор + ОЗУ = Комп.

Вот такие милые NAND. Было бы время собрал бы калькулятор на спор на одних NAND и все. Ну еще там всякая гимнастика с питанием, но это уже вспомогательно.

Где то так, вкратце. Нюансов много.

Так что NAND или NOR все встречали, точно

Были и такие заезды у любителей (несколько это пальба из пушки по воробьям - но, интересно и поучительно), собственно микропрограммы
команд CPU CISC и прошиты в локальное ПЗУ. (ну это так , к слову)

> собственно микропрограммы команд CPU CISC и прошиты в локальное ПЗУ.

Стильно. Эх бы в 80-тые махнуть. А писать на микроассемблере мне еще предстоит через месяц...

Но вообще интересно что то самому собрать. Не все же софт, и софт. Написала кто-то что-то на ассемблере и радуется - как низкоуровнево. «А ты регистр собери из деталей радиорынка, а потом сложи на нем 1212312+2123123 - вот это низкоуровнево» )))

fpga есть для этого,не ?
Ну «тяжело в учении - легко в гробу» - это еще не отменили ,да))

> fpga есть для этого,не ?

или в моем случае тетрадь. Лаба на завтра, кучу тригеров разных на завтра наделать....

карты Карно ? )

Нахрена это надо... Я понимаю аналог ramdrv.sys под /tmp (это сдела но везде и всюду), сжимать свап можно только если «железо» поддерживает (хотя я такого и не знаю), остальное - как можно более быстрый доступ память<=>свап ... Сжатие - только тормоз... При объёмах веников (даже SSD) - свап, который в отличие от винды, под линухом пользуется редко, прекрасно работает и без сжатия. Всё остальное надуманное...

И они тоже. У нас это диаграммы Вейча.

«Карты Карно были изобретены в 1952 Эдвардом В. Вейчем и усовершенствованы в 1953 Морисом Карно, физиком из «Bell Labs», и были призваны помочь упростить цифровые электронные схемы.»

Идея та же, минимизируют на ура.

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

> Очнись, запись во флеш-память всегда сопровождается предварительным стиранием, причем блок составляет, как правило, 64к.

Так вот, толстый дяденька. Это ты говоришь про NAND, где адресуется один блок и для записи одного единственного байта нужно этот блок считать целиком, изменить этот байт и записать блок обратно. NOR тем и отличается, что можно работать с отдельными байтами.

И потом, вьюноша, «быстрая и дорогая» это не NOR и не NAND. NOR - дорогая, NAND - быстрая. Если вздумал спросить «нахрена тогда нужна NOR?», подскажу: NOR - это флешка с биосом, стоит в каждой материнке.

Ещё чего расскажешь, дядечка?

> Простите за необознаность, но название пошло от логических функций NOR и NAND?

Да, память строится на ячейках того или иного типа. Разница, по-моему, вылезает в топологии, поэтому NAND можно упростить, а следовательно и удешевить, за счёт объединения в более крупные блоки данных. Для NOR это несколько сложнее. Поэтому она дорогая и область её применения — хранение небольших объёмов данных с побайтовым доступом на запись.

Если в виртуальные страницы запись не проводилась, они так и останутся «виртуальными» и в оперативку не попадут.

> Разница, по-моему, вылезает в топологии,

Комбинационный схемы будут эквивалентны. Но не внутри самого элемента. Вот там и может быть и стоимость и скорость разная

Кно-нибудь может нормально объяснить, как это работает? Есть свап, чтобы неиспользуемые (в критериях конкретного алгоритма диспетчеризации памяти) данные выкидывать на диск, освобождая тем самым ОЗУ. Никак не могу взять в толк, зачем тогда свап обратно в ОЗУ пихать?

> Интересно, а вот просто прослойка для создания сжатого блочного устройства поверх любого блочного - бывают?

cloop от доктора Клауса Кноппера и иже (как минимум, участник разработки, как максимум - автор). до Squashfs был основным способом сжатых LiveCD

> если нужен быстрый свап, ну, может какая-то софтина требует, можно создать rаm-диск, оформить его как свап и подключить.

это просто какой то праздник поехавшего виндуса головного мозга

когда свап не нужен - его ОТКЛЮЧАЮТ. swapoff и все дела. или наоборот, когда нету, но нужен, создают быстрофайлик и swapon

цель указанного патча - не сделать изврать в стиле windows (сколько тем уже видел «своп на рамдиск») а СЖАТИЕ ПАМЯТИ. ВСЁ.

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

у тебя нет «будуЮщего». будущего тоже

>Так вот, толстый дяденька. Это ты говоришь про NAND, где адресуется один блок и для записи одного единственного байта нужно этот блок считать целиком, изменить этот байт и записать блок обратно. NOR тем и отличается, что можно работать с отдельными байтами.

И как это ты собрался записывать данные во флеш без предварительного стирания целого блока? Иди неуч, книжки читай и выясни заодно как устроена NAND и NOR и что именно понимается под термином «запись во флеш-память».

Ещё чего расскажешь, дядечка?

А скажу я тебе, что перепутал ты SLC и MLC технологии с NAND и NOR. SLC действительно быстрая и дорогая по сравнению с MLC, и надежность у SLC выше. В общем учиться тебе еще и учиться.

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

Всякий шлак может быть и медленнее обычных SATA 7200, а нормальные интеловские SSD дают over 200 Mb/s на чтение (на запись поменьше, но где то под сотню дают). Это никакому обычному винту не снилось, даже SAS. разве что только рейд, но и SSD можно в рейд поставить (кажется на thg были тесты, в рейде из 8 интеловских SSD скорость чтения зашкаливала за гиг в секунду). И это все при времени доступа в десятки МИКРОсекунд (т.е. на самое меньшее в сто раз быстрее самых скоростных SAS)

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

То, что ставят в eeepc, это практически флешки начального уровня с контроллером, раскидывающим запись, чтобы флешка не запилилась быстро. Быстрые SSD - это, например, X25-M на MLC. У которых 200Mb на чтение и 70Mb на запись. А серверный вариант - это X25-E на SLC, у которых у каждого диска 200Mb чтения и 170Mb записи с практически нулевым сиком. Мы такими сервер один набили(8х32Gb), там та-а-акие показатели дисковой подсистемы, что пипец :)

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

Ну так и сейчас сунуть можно, подкрутив vm.swappiness. Зачем костыли то делать и смущать vm?

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

Уже давно одиночный X25-E на порядок быстрее на рандомных операциях, чем несколько SAS в RAID. Линейная скорость редко кому нужна. А надёжность, спросит читатель, как там с надёжностью? Уже декларируется такая же, как у HDD - MBTF около миллиона часов.

В NOR архитектуре к каждому транзистору необходимо подвести индивидуальный контакт, что увеличивает размеры схемы. Эта проблема решается с помощью NAND архитектуры.

... В результате уже не требуется подводить индивидуальный контакт к каждой ячейке, так что размер и стоимость NAND чипа может быть существенно меньше. Так же запись и стирание происходит быстрее. Однако эта архитектура не позволяет обращаться к произвольной ячейке.

NAND и NOR архитектуры сейчас существуют параллельно и не конкурируют друг с другом, поскольку находят применение в разных областях хранения данных.

це википедия

> А надёжность, спросит читатель, как там с надёжностью? Уже декларируется такая же, как у HDD - MBTF около миллиона часов.

Во-во, читатель еще и переспросит - на заборах тоже много чего задекларировано, а что там в реале? SSD, в отличии от HDD, в любом случае изнашивается операциями записи же. И что-то совсем недавно у них с этим износом была совсем жопа.

> у тебя нет «будуЮщего». будущего тоже

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

а как доставить compcache для убунты 9.10?

> а как доставить compcache для убунты 9.10?

подождать ядра .33

> а как доставить compcache для убунты 9.10?

А смысл? Оно всё равно только для эмбеддщины. Вы что, убунту туда ставить, что ли, будете?

> А как у сего патча с переносимостью?

Что имеется ввиду под переносимостью? На ARM работает без проблем, если это интересует.

> Ну так и сейчас сунуть можно, подкрутив vm.swappiness. Зачем костыли то делать и смущать vm?

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

>> а как доставить compcache для убунты 9.10?

А смысл? Оно всё равно только для эмбеддщины.

кто оно?

Вы что, убунту туда ставить, что ли, будете?

куда туда?

Типичные костыли, 1. физическая страница памяти вытесняется в своп 2. своп-страница компресится 3. сжатая своп-страница-пишется в страницу памяти физической

Итого, если просто при вытеснении страницы тупо её сжимать и оставлять на том же месте (требуется только дополнительный менеджер сжатых вытесненных страниц памяти) - получим аналогичный механизм но без промежуточного костыля.

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

да мы сегодня как раз об этом думали: сжатие просто страниц в памяти было бы более эффективно (ибо в своп дисковые кеши не кладутся)

*можно хранить не используЮ раздел подкачки на жестком диске* - Шаман такой Шаман...

А раз сжатие значит дополнительные расходы, которые могут оказаться не мальенкими. И все приемущества съедаются сокращением работы батареи нетбука.

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

если затраты на lzo окажутся хоть как-то заметными по сравнению с затратами на выделение лишней памяти - я лично съем твою батарею и шляпу