В списке рассылки разработчиков ядра Linux представлена (https://lkml.org/lkml/2012/12/11/449) технология сжатого кэширования SWAP - Zswap. Смысл технологии сводится к тому, что при необходимости выгрузки страниц памяти на диск производится попытка сжать страницы, размещая их при этом в пуле в оперативной памяти. По мере возможности сжатые страницы не выгружаются на диск чтобы избежать операций ввода/вывода с медленным носителем.
Реализация такого подхода позволяет, при возникновении необходимости сброса памяти в раздел подкачки, сократить ввод-вывод и повысить скорость работы системы в целом, за счет того, что по возможности избегается использование медленного носителя. Ценой сокращения ввода/вывода является увеличение нагрузки на процессор, который тратит дополнительные ресурсы на сжатие и распаковку данных. По утверждению разработчиков, в их конфигурации при компиляции ядра в ситуации когда происходит своппинг, выигрыш по объему ввода/вывода составил 76%, а время выполнения операции сократилось на 53%.
Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее compcache), при которой в памяти создается блочное устройство на которое производится своппинг со сжатием.
Дополнительно, можно отметить принятие (http://www.phoronix.com/scan.php?page=news_item&px=MTI1MTQ) в состав будущего ядра 3.8 патчей (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...) с реализацией поддержки механизма "huge zero_page", который в некоторых ситуациях позволят существенно (до 2.5 раз) сократить потребление физической памяти при включении в ядре поддержки Transparent Huge-Pages (THP). THP представляет собой технику увеличения базового размера адресуемых страниц памяти (ранее размер страницы составлял всегда 4096 байт, а при THP может быть увеличен до 2 или 4 Мб), что приводит к сокращению числа используемых TLB-блоков (Translation Lookaside Buffer) и расширению возможностей по задействованию выделенной, но неиспользуемой памяти, для кэширования системных данных (например, под дисковый кэш). Техника Huge zero_page расширяет возможности THP в направлении экономии пустых страниц памяти, для которых не выделяются реальные области физической памяти.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTI1MDM
Новость: https://www.opennet.ru/opennews/art.shtml?num=35610
в прошивках Андроид-а для HTC HD2 еще в прошлом году появились функции, которые позволяли задействовать zRam (сжатый swap в RAM)
Десктоп, Debian, 3.2.32, второй год полет нормальный:#!/bin/bash
echo $[2 * 1024 * 1024 * 1024] > /sys/block/zram0/disksize
mkswap -L zram /dev/zram0
swapon -p 100 /dev/zram0
Модуль ядране забываем включить /etc/modules:zram zram_num_devices=1
Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз?
> Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз?На некоторых девайсах - все шансы ощутить. На всяких там телефонах с медленным флешом на который активно свопиться беспонтово - весьма интересный вариант.
Ну учитывая, что написано про приличное использование проца, а средний ARM не есть гуд для мат. вычислений, то в лучшем случае телефоны будут мало работать, а в худшем - жарить перепелиные яйца на корпусе. Так что сложно придумать использование сей технологии.
> средний ARM не есть гуд для мат. вычисленийВо первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом.
Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет.
В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O.
>Во первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом.Какую-нибудь заглушку n2600 может быть, но n450-455 может какой-нибудь cortex-a15, но они многоядерные, хотя с конвейером помутили хорошо взамен большего потребления.
>Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет.Зато сжимать нужно достаточно много, и тут могут быть подтормаживания из-за "большой очереди".
>В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O.Полностью согласен. Кстати, это довольно частое явление, что приходится выбирать чем жертвовать - цпу или памятью.
> Какую-нибудь заглушку n2600 может быть, но n450-455 может какой-нибудь cortex-a15,Ну так процесс идет, A15-е уже временами показывают чуть ли не половину от скорости i3/i5 в ряде бенчей. У интеля нет монополии на прогресс, а у ARM с их энергоэффективностью совершенно непаханое поле в плане разгона ядра и увеличения числа ядер без вылезания за допустимый TDP. Если обратить внимание, ARMы как правило работают не то что без вентилятора (чем даже atom-ам напряжно похвастать) а чаще всего даже без какого-то особого радиатора вообще. Хотя особо мощные экспонаты могут и потребовать какой-то небольшой теплоотвод, но это явно не полкило люминя как на интеле в случае пассива традиционно висит.
> но они многоядерные, хотя с конвейером помутили хорошо взамен большего потребления.
И тем не менее, оно на ура обставляет интель по соотношению производительности к потреблению. Даже при более дубовых нормах. Не зря интель готовится в режиме чипмейкера другим чипы печь.
> Зато сжимать нужно достаточно много, и тут могут быть подтормаживания
> из-за "большой очереди".Может так выйти что это будет в целом и быстрее и меньше нагрузка на CPU. Это не прикол, в некоторых системах I/O с флешом/SD картами весьма дорогое по ресурсам процессора. Кстати и обычные механические диски могут ускориться при сжатии. LZO на современном проце в состоянии жать быстрее чем 150Мб/сек (выжимаемые в лучшем случае механическим диском). По поводу чего если посмотреть на бенчи btrfs, можно узреть как оно становится быстрее при включении сжатия. Хотя, казалось бы, появляется дополнительная операциа. Ан нет, сокращение объема I/O перевешивает повышение нагрузки на проц.
> Полностью согласен. Кстати, это довольно частое явление, что приходится выбирать чем жертвовать
> - цпу или памятью.А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.
>Ну так процесс идет, A15-е уже временами показывают чуть ли не половину от скорости i3/i5 в ряде бенчей.Тут уже нужны пруфы, ибо уж больно громкие слова. К тому же помню находил информацию, что на уровне серверов, энергоэффективность Зионов идёт выше чем у ARM-кластеров. Если интересно, то могу поискать.
>Кстати и обычные механические диски могут ускориться при сжатии. LZO на современном проце в состоянии жать быстрее чем 150Мб/секЭто да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода.
>А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.Но для телефонов это бессмысленно. : )
> Тут уже нужны пруфы, ибо уж больно громкие слова.Идете на тот же фороникс и смотрите бенчи армов между собой и vs x86, например. Там такого счастья - есть.
> К тому же помню находил информацию, что на уровне серверов, энергоэффективность
> Зионов идёт выше чем у ARM-кластеров.Наверное именно поэтому нынче ARM в сервера вдарился, ага. Всякие там Calxeda и прочие что-то полезли новый рынок окучивать, а с выходом в массы 64-битного ARM с виртуализацией и прочая интелу имхо будет весело :)
> Если интересно, то могу поискать.
Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря о том сколько независимых серверов упихивается в 1 стойку, какой TDP проца называется и прочая.
> Это да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода.
Ну а в мобилках всяких все пропорционально хилее. И I/O - тоже. Поэтому ARMу из смарта и не требуется 150 мб/сек выжимать. Кстати если вы вдруг не заметили, нынче аж 8-ядерные процы для планшетов и мобил собираются клепать.
>>А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.
> Но для телефонов это бессмысленно. : )Напротив, там обычно очень тормозное I/O, так что в смартах и планшетах у технологии есть все шансы себя проявить. Вон там выше народец даже упоминает конкретные примеры юзежа подобных по смыслу технологий.
> Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря
> о том сколько независимых серверов упихивается в 1 стойку, какой TDP
> проца называется и прочая.Calxeda & co будто бы отчаянно избегают называния цифр по энергоэффективности на операцию -- скажем, "обслужить миллион запросов". Тесты, которые на подручном оборудовании делали коллеги, показали бОльшую энергоэффективность того же C2Q перед A8 на обслуживании DNS-запросов, ЕМНИП.
На ARM может получиться куда более осмысленно предоставить _физически_ отдельную железку человеку/задачке. Но вот с ваттами под нагрузку тут лучше не судить опрометчиво.
А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :)
> А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :)SPARC'и
> Calxeda & co будто бы отчаянно избегают называния цифр по энергоэффективности на
> операцию -- скажем, "обслужить миллион запросов".Вообще да, любопытно. Сам ARM вообще-то любит понтоваться mips/watt технично подтрунивая над интелом. У которого и сами процы ничего шедеврального не показывают и оверхед от кучи обвязки большой (холостого потребления типового писюка хватит чтобы накормить добрую дюжину полностью нагруженных ARMов).
> Тесты, которые на подручном оборудовании делали коллеги, показали
> бОльшую энергоэффективность того же C2Q перед A8 на обслуживании DNS-запросов, ЕМНИП.1) А как все это мерялось? A8 - сферическое ядро в вакууме. Конкретные инкарнации изрядно отличаются по свойствам.
1.1) А двухъядерный A15 от самсуня, например, разгоняется в бенчах до чуть ли не половины скорости i5. А вот его радиатору при этом позавидует не то что i5, а любой атом. Ну, современное ядро на не сильно древних техпроцессах. Вот и...
2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей. Реально же сервера зачастую недогружены. Ну, стоит сервак с DNSом допустим внутри конторы в интранете. Откуда ему миллион запросов свалится? Он большую часть времени груши околачивает. При этом идет холостое потребление. Но DNS - нужен. Значит кто-то его должен обслужить. Значит надо сервер. Откуда-то отсюда и возникает спрос на небольшие и мало кушающие сервера, всякие виртуалки и прочая. Т.к. если влобовую воткнуть ваш C2 - это здоровая дура, которая на холостом ходу жрет как целое ведро полностью озадаченных ARMов A8.
3) Не забываем что A8 зачастую делают для удешевления производства по достаточно дубовым техпроцессам, по поводу чего у интеля бывает некая не совсем честная фора. Емкость элементов схемы падает по мере мельчания процесса и при равном числе переключений более тонкая схема жрет меньше, сэкономив на перезаряде емкостей. Так что если хочется сравнивать эффективность ядер - логично по крайней мере выбрать A8 на нанометраже не сильно далеким от конкурента. Зато процы по более дубовому нанометражу - дешевле, т.к. позволяют юзать устаревшее оборудование с неким профитом. A8 по относительно дубовому нанометражу стоит $5 за чип. Обвязки ему надо минимум. И вся система может стоить $20 например, как у Pi. А у интела таких цен в принципе не бывает. А на холостое потребление самого дешевого селерона можно накормить несколько полностью прогруженных ARM :)
4) У интела есть еще и обвязка которая жрет немеряно. Мощности которую жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :). При том эта мощща вообще обычно жрется независимот от того работает проц или нет.> На ARM может получиться куда более осмысленно предоставить _физически_
> отдельную железку человеку/задачке.Логично. Виртуалки btw, тоже именно об этом, только с другого бока - попытка сделать из того что уже есть то что хотелось получить.
> Но вот с ваттами под нагрузку тут лучше не судить опрометчиво.
Опрометчиво - да. Как минимум стоит учитывать что CMOS схемы под нагрузкой жрут прямо пропорционально размеру элемента, так что сравнивать в указанном контексте имеет смысл как минимум ядра отлитые по более-менее одинаковым нанометрам.
> 1) А как все это мерялось? A8 - сферическое ядро в вакууме.
> Конкретные инкарнации изрядно отличаются по свойствам.Понимаю, но даже не помню, какая именно это борда была -- надо уточнить, сейчас это неудобно (возможно, i.MX53).
> 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей.
Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов.
> А на холостое потребление [...]
И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :)
> 4) У интела есть еще и обвязка которая жрет немеряно. Мощности которую
> жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :).Угу, помню и двадцативаттные контроллеры FBDIMM...
> Понимаю, но даже не помню, какая именно это борда была -- надо
> уточнить, сейчас это неудобно (возможно, i.MX53).Да я этом к тому что миллион запросов сам по себе - нечто сферическое и в вакууме. Роялит еще и время за которое он приехал. При высокой интенсивности запросов интел может попытаться скрасить немеряное потребление в холостом режиме ломовой производительностью. При низкой - ARM на полной загрузке будет жрать в 10 раз меньше чем интел на холостом ходу. Интел сделал нулевую с точки зрения окружающих работу а сожрал больше. Забавно, да? :)
>> 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей.
> Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов.Идеально прогрузить сервер на 100% задача нетривиальная. Даже в всепланетном масштабе потребление ресурсов колеблется например в зависимости от времени суток. Так что или сервак зашьется в час пик или будет недогружен когда все дрыхнут.
Ну и вообще. Надо вот кому-то днс. Может он и не генерит миллионы запросов но не хочет зависеть от закидонов сторонних серваков, хочет свою "локалочную" DNS зону и прочая. Вполне валидное и даже типовое желание. ARM в этом плане может смотреться любопытно, т.к. фундаментально меньше жрет, занимает мизер места, а миллион запросов ему присылать будут достаточно долго :)
> И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :)
Ну да :)
>> жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :).
> Угу, помню и двадцативаттные контроллеры FBDIMM...Да собственно у интеля чипсеты вообще холодностью не отличаются. Да и у AMD. Какие-то потуги в этом направлении видны только в атомах. Которых ARM нынче обставляют даже в производительности. Ну им то не надо таскать вагон сложной системной логики с элементами легаси барахла.
Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работу какого-нибудь генератора не очень плотных объемных данных с выводом даже на диск с быстрым SATA, не то, что на флешку.
> Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работуОчень уж иногда, ибо 2-стадийный LZ+Huffman, который по определению не будет чемпионом скорости. Быстрые алгоритмы обычно являют собой максимально простой и шустрый LZ, такой может разогнаться до весьма убедительных величин.
вот насчет атома не могу сказать, но eepc700 (проц celeron 600mzh ram 512) работает под андроидом 4 шустрее чем rockchip2819 1Ghz + 1G ram
про батарейку молчу да рокчип меньше ее жрет
zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство.
zram - сжатое блочное устройство в памяти.Работают на разных уровнях.
>zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство.
>zram - сжатое блочное устройство в памяти....а также может выступать в качестве компрессирующего прокси для свопа на диске.
> zRamНаписано же - не путайте. Суть похожая но реализация весьма разная.
Я вот, то же подумал...боян же...не? zram был давненько и в чем разница? Можно было и tmpfs заюзать ранее. zram я пользовался года полтора наверное, потом памяти до 8Гб нарастил и забил как то на нее. Нипонятно мне.
анналогично =)
> анналогично =)Может не обязательно публично тупить на форуме и демонстрировать безграмотность? Это вас обоих касается :)
Явно же шпилька со стороны Привидения была, мистер урезониватель )
помню, была похожая программа для windows 3.1, qemm называлась
> помню, была похожая программа для windows 3.1, qemm называласьНет, 4dos.
Прога была 4дос, а запускался с нее виндус, когда она была в config.sys залита и autoexec.bat :)
Только, наверное, не совсем правильно называть это "кэшированием раздела подкачки".
правильно. Это скорее менеджер сжатых страниц с сомнительной областью применения. В упомянутых выше мобильных девайсах и так сильная нехватка процессорной мощности, что упаковка-распаковка там лишняя, в серверах/станциях память не такой ресурс, на котором экономят. Остаются только нетбуки/ноуты с с быстрым SSD, которым тоже, в общем то по-барану )
> выше мобильных девайсах и так сильная нехватка процессорной мощности,Мощность проца которая тратится на работу с контроллером SD карты или NAND флеша может спокойно перевесить затраты на сжатие.
наоборот
> наоборотИ в скольких девайсах вы это меряли? У меня вот есть девайс с столь медленным I/O что при записи в флеш он упирается в ... 100% CPU usage. Ежику понятно что у легкого сжатия там все шансы скостить нагрузку.
> Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее
> compcache), при которой в памяти создается блочное устройство на которое производится
> своппинг со сжатием.Так чего тут путать - и то и дугое абсолютно бесполезная херня.
Для ПК на x86_64 с 4Гб+ оперативой согласен, но для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться.
> Для ПК на x86_64 с 4Гб+ оперативой согласенЕще бы не согласиться - греть воздух вместо того чтобы сбалансированно подбирать железо
> для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться
там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовали в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают, к тому же другие скоростные интерфейсы типа sata или ddr mmc давно уже не редкость на армах
> там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовалиПростите, уже выпущена туева хуча чипов. Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN.
> в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают,
При том - IIRC там довольно тормозной zlib.
> к тому же другие скоростные интерфейсы типа sata
> или ddr mmc давно уже не редкость на армахОни конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает. А механические диски не любят seek. А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда. А также дорого и жруче.
> Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN.вот ты горе-аналитик, такие как ты и разрабатывают Linux, головкой своей подумай что лучше - копировать за счет процессора или за счет контроллера DMA.
> При том - IIRC там довольно тормозной zlib
неповезло вам - у меня lzo там
> Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает.
но там ставят eMMC с DDR
> А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда
ты хотя бы uSD видел (для справки там NAND внутри с аппартаным контроллером) ? чего и куда некуда
> вот ты горе-аналитик, такие как ты и разрабатывают Linux,А вы, наверное, Д`Артаньян? :) Да, линукс разрабатывают практики. Которым надо ехать. Сегодня. Желательно с комфортом. А не "через 10 лет у меня мог бы быть намного более крутой автомобиль, поэтому сегодня пойдем пешком". Задача "ехать" (и желательно хорошо) стоит сегодня. А не когда чипмейкеры соизволят надизайнить расово верные чипы, с блекдж^W DMA и прочими наворотами.
> головкой своей подумай
Нет уж, это вы как-нибудь сами думайте этим :P.
> что лучше - копировать за счет процессора или за счет контроллера DMA.
Ну я как бы в курсе. Но реальный мир имеет свойство отличаться от идеала. А не хотите зарплату получать лишь после того как чипмейкеры расово верные чипы отольют? А до этого - покантуйтесь уж как-нибудь. Ведь если вас послушать - до тех пор надо, очевидно, груши околачивать.
>> При том - IIRC там довольно тормозной zlib
> неповезло вам - у меня lzo тамНу так это еще ничего, lzo на минимальном сжатии резвенький. Хотя извращенцев которые бы свопились на файл в JFFS я все-таки не встречал.
>> Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает.
> но там ставят eMMC с DDRИ что? В целом оно обычно оказывается карманным вариантом героя. В настоящем SSD например запихана целая пачка чипов флеша, которые работают одновременно. Могу себе представить как контроллер SSD запустив erase в одном из чипов пойдет и тем временем запишет в соседний, обеспечив непрерывность потока данных. Но в мобилу такие понты и навороты не влезут ни по размеру ни по потреблению. А сам по себе флеш - не больно какой быстрый на запись носитель. В SSD это лечится юзанием кучи чипов. И даже так оно на запись заметно медленнее чем на чтение.
> ты хотя бы uSD видел (для справки там NAND внутри с аппартаным контроллером) ? чего и куда некуда
Да, там NAND и контроллер. Но это не значит что там впихнут 16 чипаков NAND вкалывающих параллельно и топовый контроллер как в SSD. По поводу чего производительность будет более другой.
> Хотя извращенцев которые бы свопились на файл в JFFS я все-таки не встречал.Я вообще не встречал чтобы на ARM использовали swap - поэтому говорю что это бесполезные затеи, а если тебе так нужно - можно свопиться в файл на быстром носителе типа nand.
> Да, там NAND и контроллер. Но это не значит что там впихнут 16 чипаков NAND вкалывающих
параллельно и топовый контроллер как в SSD.
ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd.
> Я вообще не встречал чтобы на ARM использовали swapЗато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает. Например в том же N900 все это есть. И работает довольно так себе. Такие технологии имеют все шансы это улучшить.
> - поэтому говорю что это бесполезные затеи, а если тебе так нужно - можно
> свопиться в файл на быстром носителе типа nand.Не такой уж он и быстрый, а в некоторых железяках еще и проц грузит. И еще вопрос на что циклов больше уйдет - на скоростное сжатие или окучивание контроллера NAND в конкретной системе.
> ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd.
Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты памяти, только в виде чипа.
> Зато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает.
> Например в том же N900 все это есть.Правильно ли я понял что их "заводская" прошивка штатно использует swap ? Если это так - я не удивлен что их там разогнали к херям :)
> Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты
> памяти, только в виде чипа.Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти.
> Правильно ли я понял что их "заводская" прошивка штатно использует swap ?Да, для возможности запускать больше программ в ограниченных ресурсах. То что своп на флеше может неплохо работать - было замечено юзерами еще Nokia 770. Они стали делать свопы на картах. Нокия пошла навстречу и в N800/810 сие было сделано опционально, а в N900 и вовсе по дефолту активировано. Просто на те поры нокия умела делать не более 256Мб RAM, а это не то чтобы совсем мало, но достаточно душно для реально многозадачного девайса. На котором натурально хочется запустить кучу всего. Ну там браузер, аську, плеер, почтарь, еще кучу всего.
> Если это так - я не удивлен что их там разогнали к херям :)
Разогнал их гражданин элоп-остолоп сугубо потому что они очень уж мешались его винде горбатой.
> Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти.
Как бы еще от контроллера SoC зависит и прочая. У омапа в целом на том же N900 скорость не вызывает отпадение челюсти, например. Но своп там не так уж бесполезен т.к. seek time небольшой. Затыкаться оно начинает когда памяти очень грубо не хватает и рабочий набор перестал лезть в оперативку.
> Так чего тут путать - и то и дугое абсолютно бесполезная херня.Ну ты так и скажи что ты это видел только на картинке, а дальше писюка с ...цать гигз оперативы - не видишь.
Сплошные упоминания в новостях про нововведения в 3.8. Похоже, тот еще торт будет! Главное не ставить все это добро сразу в продакшн ;)
> "huge zero_page"Думаю, лучше почитать здесь, чем на форониксе: http://lwn.net/Articles/517465/
Похоже скоро будем ждать аппаратных решений
ну его на фиг, такое - это ж маркетолухи такого понапишут - не поймёшь,сколько реально памяти в железке... Нет уж, мне разных даблспейсов хватило в своё время
>Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее compcache), при которой в памяти создается блочное устройство на которое производится своппинг со сжатием.Им бы названиями поменяться.;d
А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?
тогда наступит сингулярность
> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая конфигурация для этого нужна.
>> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?
> Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая
> конфигурация для этого нужна.Как вариант - плющить данные на лету легким режимом xz,
и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA.
>Как вариант - плющить данные на лету легким режимом xz,xz эффективен на больших размерах блока, а не на блоках размером в страницу.
> Как вариант - плющить данные на лету легким режимом xz,
> и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA.Павлин, xz это и есть LZMA, просто у остроконечников и тупоконечников как обычно нет единства насчет того в каком формате сжатый поток оформлять. Это единственное отличие в всех этих подвидах, сам LZMA лежащий в их основе - одинаковый :)
Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^
:)
> Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^В сильно некоторых случаях может удасться отыграть немного :)
Например зипуете файл на несколько гигз состоящий из нулей. А потом зипуете такой зип. Сожмется.
Ждем в ванильном и в основных дистрах!
На диск тоже лучше сжатое класть. Диск сейчас узкое место, а не проц.
> Диск сейчас узкое место, а не проц.Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты.
>Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты.Да. Вот только посмотри во сколько раз возросла скорость записи на диск и в память за последние 10-15 лет. Подсказка: сравнение не в пользу дисков.
>>Диск ВСЕГДА был узким местом.
> Подсказка: сравнение не в пользу дисков.Эм, см выше 0:)
Ок, сейчас диск стал более узким местом.
> Диск ВСЕГДА был узким местом.Просто как-то так вышло что раньше процы были дохлее а скоростные алгоритмы сжатия не настолько развиты. По поводу чего сжатие если и применялось то не с целью выиграть в скорости а скорее место на диске сэкономить. На данный момент оно может убить 2 зайцев сразу. LZO/lz4/... могут жать с настолько зубодробильной скоростью что сжатая запись окажется быстрее за счет сокращения I/O. А уж чтение и подавно - такие алгоритмы дико быстры в распаковке. В ряде случаев они могут обогнать memcpy() за счет снижения объема читаемых данных при равном объеме записи ;)