URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 87763
[ Назад ]

Исходное сообщение
"Для Linux представлена технология сжатого кеширования раздел..."

Отправлено opennews , 14-Дек-12 22:11 
В списке рассылки разработчиков ядра 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
Новость: http://www.opennet.me/opennews/art.shtml?num=35610


Содержание

Сообщения в этом обсуждении
"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено VecH , 14-Дек-12 22:11 
в прошивках Андроид-а для HTC HD2 еще в прошлом году появились функции, которые позволяли задействовать zRam (сжатый swap в RAM)

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено rshadow , 14-Дек-12 22:38 
Десктоп, 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


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено rshadow , 14-Дек-12 22:39 
Модуль ядране забываем включить /etc/modules:

zram zram_num_devices=1


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено DannyBoy , 14-Дек-12 22:51 
Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз?

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 14-Дек-12 23:13 
> Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз?

На некоторых девайсах - все шансы ощутить. На всяких там телефонах с медленным флешом на который активно свопиться беспонтово - весьма интересный вариант.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено DannyBoy , 14-Дек-12 23:18 
Ну учитывая, что написано про приличное использование проца, а средний ARM не есть гуд для мат. вычислений, то в лучшем случае телефоны будут мало работать, а в худшем - жарить перепелиные яйца на корпусе. Так что сложно придумать использование сей технологии.

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 00:09 
> средний ARM не есть гуд для мат. вычислений

Во первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом.
Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет.
В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено DannyBoy , 15-Дек-12 00:17 
>Во первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом.

Какую-нибудь заглушку n2600 может быть, но n450-455 может какой-нибудь cortex-a15, но они многоядерные, хотя с конвейером помутили хорошо взамен большего потребления.
>Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет.

Зато сжимать нужно достаточно много, и тут могут быть подтормаживания из-за "большой очереди".
>В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O.

Полностью согласен. Кстати, это довольно частое явление, что приходится выбирать чем жертвовать - цпу или памятью.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 08:36 
> Какую-нибудь заглушку n2600 может быть, но n450-455 может какой-нибудь cortex-a15,

Ну так процесс идет, A15-е уже временами показывают чуть ли не половину от скорости i3/i5 в ряде бенчей. У интеля нет монополии на прогресс, а у ARM с их энергоэффективностью совершенно непаханое поле в плане разгона ядра и увеличения числа ядер без вылезания за допустимый TDP. Если обратить внимание, ARMы как правило работают не то что без вентилятора (чем даже atom-ам напряжно похвастать) а чаще всего даже без какого-то особого радиатора вообще. Хотя особо мощные экспонаты могут и потребовать какой-то небольшой теплоотвод, но это явно не полкило люминя как на интеле в случае пассива традиционно висит.

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

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

> Зато сжимать нужно достаточно много, и тут могут быть подтормаживания
> из-за "большой очереди".

Может так выйти что это будет в целом и быстрее и меньше нагрузка на CPU. Это не прикол, в некоторых системах I/O с флешом/SD картами весьма дорогое по ресурсам процессора. Кстати и обычные механические диски могут ускориться при сжатии. LZO на современном проце в состоянии жать быстрее чем 150Мб/сек (выжимаемые в лучшем случае механическим диском). По поводу чего если посмотреть на бенчи btrfs, можно узреть как оно становится быстрее при включении сжатия. Хотя, казалось бы, появляется дополнительная операциа. Ан нет, сокращение объема I/O перевешивает повышение нагрузки на проц.

> Полностью согласен. Кстати, это довольно частое явление, что приходится выбирать чем жертвовать
> - цпу или памятью.

А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено DannyBoy , 15-Дек-12 10:16 
>Ну так процесс идет, A15-е уже временами показывают чуть ли не половину от скорости i3/i5 в ряде бенчей.

Тут уже нужны пруфы, ибо уж больно громкие слова. К тому же помню находил информацию, что на уровне серверов, энергоэффективность Зионов идёт выше чем у ARM-кластеров. Если интересно, то могу поискать.
>Кстати и обычные механические диски могут ускориться при сжатии. LZO на современном проце в состоянии жать быстрее чем 150Мб/сек

Это да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода.
>А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.

Но для телефонов это бессмысленно. : )


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 17:41 
> Тут уже нужны пруфы, ибо уж больно громкие слова.

Идете на тот же фороникс и смотрите бенчи армов между собой и vs x86, например. Там такого счастья - есть.

> К тому же помню находил информацию, что на уровне серверов, энергоэффективность
> Зионов идёт выше чем у ARM-кластеров.

Наверное именно поэтому нынче ARM в сервера вдарился, ага. Всякие там Calxeda и прочие что-то полезли новый рынок окучивать, а с выходом в массы 64-битного ARM с виртуализацией и прочая интелу имхо будет весело :)

> Если интересно, то могу поискать.

Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря о том сколько независимых серверов упихивается в 1 стойку, какой TDP проца называется и прочая.

> Это да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода.

Ну а в мобилках всяких все пропорционально хилее. И I/O - тоже. Поэтому ARMу из смарта и не требуется 150 мб/сек выжимать. Кстати если вы вдруг не заметили, нынче аж 8-ядерные процы для планшетов и мобил собираются клепать.

>>А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM.
> Но для телефонов это бессмысленно. : )

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


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Michael Shigorin , 15-Дек-12 17:51 
> Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря
> о том сколько независимых серверов упихивается в 1 стойку, какой TDP
> проца называется и прочая.

Calxeda & co будто бы отчаянно избегают называния цифр по энергоэффективности на операцию -- скажем, "обслужить миллион запросов".  Тесты, которые на подручном оборудовании делали коллеги, показали бОльшую энергоэффективность того же C2Q перед A8 на обслуживании DNS-запросов, ЕМНИП.

На ARM может получиться куда более осмысленно предоставить _физически_ отдельную железку человеку/задачке.  Но вот с ваттами под нагрузку тут лучше не судить опрометчиво.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Romik , 15-Дек-12 22:11 
А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :)

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Romik , 15-Дек-12 22:13 
> А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :)

SPARC'и


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 16-Дек-12 17:37 
> 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 схемы под нагрузкой жрут прямо пропорционально размеру элемента, так что сравнивать в указанном контексте имеет смысл как минимум ядра отлитые по более-менее одинаковым нанометрам.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Michael Shigorin , 17-Дек-12 02:42 
> 1) А как все это мерялось? A8 - сферическое ядро в вакууме.
> Конкретные инкарнации изрядно отличаются по свойствам.

Понимаю, но даже не помню, какая именно это борда была -- надо уточнить, сейчас это неудобно (возможно, i.MX53).

> 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей.

Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов.

> А на холостое потребление [...]

И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :)

> 4) У интела есть еще и обвязка которая жрет немеряно. Мощности которую
> жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :).

Угу, помню и двадцативаттные контроллеры FBDIMM...


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 17-Дек-12 17:25 
> Понимаю, но даже не помню, какая именно это борда была -- надо
> уточнить, сейчас это неудобно (возможно, i.MX53).

Да я этом к тому что миллион запросов сам по себе - нечто сферическое и в вакууме. Роялит еще и время за которое он приехал. При высокой интенсивности запросов интел может попытаться скрасить немеряное потребление в холостом режиме ломовой производительностью. При низкой - ARM на полной загрузке будет жрать в 10 раз меньше чем интел на холостом ходу. Интел сделал нулевую с точки зрения окружающих работу а сожрал больше. Забавно, да? :)

>> 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей.
> Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов.

Идеально прогрузить сервер на 100% задача нетривиальная. Даже в всепланетном масштабе потребление ресурсов колеблется например в зависимости от времени суток. Так что или сервак зашьется в час пик или будет недогружен когда все дрыхнут.

Ну и вообще. Надо вот кому-то днс. Может он и не генерит миллионы запросов но не хочет зависеть от закидонов сторонних серваков, хочет свою "локалочную" DNS зону и прочая. Вполне валидное и даже типовое желание. ARM в этом плане может смотреться любопытно, т.к. фундаментально меньше жрет, занимает мизер места, а миллион запросов ему присылать будут достаточно долго :)

> И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :)

Ну да :)

>> жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :).
> Угу, помню и двадцативаттные контроллеры FBDIMM...

Да собственно у интеля чипсеты вообще холодностью не отличаются. Да и у AMD. Какие-то потуги в этом направлении видны только в атомах. Которых ARM нынче обставляют даже в производительности. Ну им то не надо таскать вагон сложной системной логики с элементами легаси барахла.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 08:57 
Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работу какого-нибудь генератора не очень плотных объемных данных с выводом даже на диск с быстрым SATA, не то, что на флешку.

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 17:42 
> Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работу

Очень уж иногда, ибо 2-стадийный LZ+Huffman, который по определению не будет чемпионом скорости. Быстрые алгоритмы обычно являют собой максимально простой и шустрый LZ, такой может разогнаться до весьма убедительных величин.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Admin1 , 15-Дек-12 21:46 
вот насчет атома не могу сказать, но eepc700 (проц celeron 600mzh ram 512) работает под андроидом 4 шустрее чем rockchip2819 1Ghz + 1G ram
про батарейку молчу да рокчип меньше ее  жрет

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Просто прохожий , 14-Дек-12 22:50 
zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство.
zram - сжатое блочное устройство в памяти.

Работают на разных уровнях.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Led , 16-Дек-12 02:26 
>zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство.
>zram - сжатое блочное устройство в памяти.

...а также может выступать в качестве компрессирующего прокси для свопа на диске.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 14-Дек-12 23:09 
> zRam

Написано же - не путайте. Суть похожая но реализация весьма разная.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено 3draven , 14-Дек-12 22:42 
Я вот, то же подумал...боян же...не? zram был давненько и в чем разница? Можно было и tmpfs заюзать ранее. zram я пользовался года полтора наверное, потом памяти до 8Гб нарастил и забил как то на нее. Нипонятно мне.

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено rshadow , 14-Дек-12 22:50 
анналогично =)

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 14-Дек-12 23:16 
> анналогично =)

Может не обязательно публично тупить на форуме и демонстрировать безграмотность? Это вас обоих касается :)


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 16-Дек-12 09:23 
Явно же шпилька со стороны Привидения была, мистер урезониватель )

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Нанобот , 14-Дек-12 22:52 
помню, была похожая программа для windows 3.1, qemm называлась

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Andrey Mitrofanov , 14-Дек-12 22:55 
> помню, была похожая программа для windows 3.1, qemm называлась

Нет, 4dos.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено 3draven , 14-Дек-12 23:10 
Прога была 4дос, а запускался с нее виндус, когда она была в config.sys залита и autoexec.bat :)

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено YetAnotherOnanym , 14-Дек-12 23:16 
Только, наверное, не совсем правильно называть это "кэшированием раздела подкачки".

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено pro100master , 15-Дек-12 01:16 
правильно. Это скорее менеджер сжатых страниц с сомнительной областью применения. В упомянутых выше мобильных девайсах и так сильная нехватка процессорной мощности, что упаковка-распаковка там лишняя, в серверах/станциях память не такой ресурс, на котором экономят. Остаются только нетбуки/ноуты с с быстрым SSD, которым тоже, в общем то по-барану )

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 08:37 
> выше мобильных девайсах и так сильная нехватка процессорной мощности,

Мощность проца которая тратится на работу с контроллером SD карты или NAND флеша может спокойно перевесить затраты на сжатие.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 15:19 
наоборот

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 17:44 
> наоборот

И в скольких девайсах вы это меряли? У меня вот есть девайс с столь медленным I/O что при записи в флеш он упирается в ... 100% CPU usage. Ежику понятно что у легкого сжатия там все шансы скостить нагрузку.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено sasa , 15-Дек-12 02:33 
> Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее
> compcache), при которой в памяти создается блочное устройство на которое производится
> своппинг со сжатием.

Так чего тут путать - и то и дугое абсолютно бесполезная херня.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено ILYA INDIGO , 15-Дек-12 04:10 
Для ПК на x86_64 с 4Гб+ оперативой согласен, но для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться.

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено sasa , 15-Дек-12 10:29 
> Для ПК на x86_64 с 4Гб+ оперативой согласен

Еще бы не согласиться - греть воздух вместо того чтобы сбалансированно подбирать железо

> для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться

там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовали в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают, к тому же другие скоростные интерфейсы типа sata или ddr mmc давно уже не редкость на армах


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 17:55 
> там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовали

Простите, уже выпущена туева хуча чипов. Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN.

> в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают,

При том - IIRC там довольно тормозной zlib.

> к тому же другие скоростные интерфейсы типа sata
> или ddr mmc давно уже не редкость на армах

Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает. А механические диски не любят seek. А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда. А также дорого и жруче.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено sasa , 16-Дек-12 16:15 
>  Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN.

вот ты горе-аналитик, такие как ты и разрабатывают Linux, головкой своей подумай что лучше - копировать за счет процессора или за счет контроллера DMA.

> При том - IIRC там довольно тормозной zlib

неповезло вам - у меня lzo там

> Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает.

но там ставят eMMC с DDR

> А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда

ты хотя бы uSD видел (для справки там NAND внутри с аппартаным контроллером) ? чего и куда некуда


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 16-Дек-12 18:12 
> вот ты горе-аналитик, такие как ты и разрабатывают Linux,

А вы, наверное, Д`Артаньян? :) Да, линукс разрабатывают практики. Которым надо ехать. Сегодня. Желательно с комфортом. А не "через 10 лет у меня мог бы быть намного более крутой автомобиль, поэтому сегодня пойдем пешком". Задача "ехать" (и желательно хорошо) стоит сегодня. А не когда чипмейкеры соизволят надизайнить расово верные чипы, с блекдж^W DMA и прочими наворотами.

> головкой своей подумай

Нет уж, это вы как-нибудь сами думайте этим :P.

> что лучше - копировать за счет процессора или за счет контроллера DMA.

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

>> При том - IIRC там довольно тормозной zlib
> неповезло вам - у меня lzo там

Ну так это еще ничего, lzo на минимальном сжатии резвенький. Хотя извращенцев которые бы свопились на файл в JFFS я все-таки не встречал.

>> Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает.
> но там ставят eMMC с DDR

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

> ты хотя бы uSD видел (для справки там NAND внутри с аппартаным контроллером) ? чего и куда некуда

Да, там NAND и контроллер. Но это не значит что там впихнут 16 чипаков NAND вкалывающих параллельно и топовый контроллер как в SSD. По поводу чего производительность будет более другой.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено sasa , 16-Дек-12 22:25 
> Хотя извращенцев которые бы свопились на файл в JFFS я все-таки не встречал.

Я вообще не встречал чтобы на ARM использовали swap - поэтому говорю что это бесполезные затеи, а если тебе так нужно - можно свопиться в файл на быстром носителе типа nand.

> Да, там NAND и контроллер. Но это не значит что там впихнут 16 чипаков NAND вкалывающих

параллельно и топовый контроллер как в SSD.

ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 17-Дек-12 17:34 
> Я вообще не встречал чтобы на ARM использовали swap

Зато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает. Например в том же N900 все это есть. И работает довольно так себе. Такие технологии имеют все шансы это улучшить.

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

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

> ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd.

Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты памяти, только в виде чипа.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено sasa , 18-Дек-12 12:58 
> Зато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает.
> Например в том же N900 все это есть.

Правильно ли я понял что их "заводская" прошивка штатно использует swap ? Если это так - я не удивлен что их там разогнали к херям :)

> Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты
> памяти, только в виде чипа.

Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 20-Янв-13 22:01 
> Правильно ли я понял что их "заводская" прошивка штатно использует swap ?

Да, для возможности запускать больше программ в ограниченных ресурсах. То что своп на флеше может неплохо работать - было замечено юзерами еще Nokia 770. Они стали делать свопы на картах. Нокия пошла навстречу и в N800/810 сие было сделано опционально, а в N900 и вовсе по дефолту активировано. Просто на те поры нокия умела делать не более 256Мб RAM, а это не то чтобы совсем мало, но достаточно душно для реально многозадачного девайса. На котором натурально хочется запустить кучу всего. Ну там браузер, аську, плеер, почтарь, еще кучу всего.

> Если это так - я не удивлен что их там разогнали к херям :)

Разогнал их гражданин элоп-остолоп сугубо потому что они очень уж мешались его винде горбатой.

> Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти.

Как бы еще от контроллера SoC зависит и прочая. У омапа в целом на том же N900 скорость не вызывает отпадение челюсти, например. Но своп там не так уж бесполезен т.к. seek time небольшой. Затыкаться оно начинает когда памяти очень грубо не хватает и рабочий набор перестал лезть в оперативку.


"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Аноним , 15-Дек-12 08:37 
> Так чего тут путать - и то и дугое абсолютно бесполезная херня.

Ну ты так и скажи что ты это видел только на картинке, а дальше писюка с ...цать гигз оперативы - не видишь.



"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Loooooker , 15-Дек-12 05:31 
Сплошные упоминания в новостях про нововведения в 3.8. Похоже, тот еще торт будет! Главное не ставить все это добро сразу в продакшн ;)

"Для Linux представлена технология сжатого кеширования раздел..."
Отправлено Michael Shigorin , 15-Дек-12 11:29 
> "huge zero_page"

Думаю, лучше почитать здесь, чем на форониксе: http://lwn.net/Articles/517465/


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено psevdozebra , 15-Дек-12 12:43 
Похоже скоро будем ждать аппаратных решений

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Crazy Alex , 15-Дек-12 17:30 
ну его на фиг, такое - это ж маркетолухи такого понапишут - не поймёшь,сколько реально памяти в железке... Нет уж, мне разных даблспейсов хватило в своё время

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 15-Дек-12 13:02 
>Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее compcache), при которой в памяти создается блочное устройство на которое производится своппинг со сжатием.

Им бы названиями поменяться.;d


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 15-Дек-12 13:55 
А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено pavlinux , 15-Дек-12 17:29 
тогда наступит сингулярность

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 15-Дек-12 17:58 
> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?

Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая конфигурация для этого нужна.


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено pavlinux , 15-Дек-12 21:32 
>> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?
> Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая
> конфигурация для этого нужна.

Как вариант - плющить данные на лету легким режимом xz,
и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA.


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Led , 16-Дек-12 02:31 
>Как вариант - плющить данные на лету легким режимом xz,

xz эффективен на больших размерах блока, а не на блоках размером в страницу.


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 16-Дек-12 18:16 
> Как вариант - плющить данные на лету легким режимом xz,
> и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA.

Павлин, xz это и есть LZMA, просто у остроконечников и тупоконечников как обычно нет единства насчет того в каком формате сжатый поток оформлять. Это единственное отличие в всех этих подвидах, сам LZMA лежащий в их основе - одинаковый :)


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено kai , 16-Дек-12 01:28 
Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено pavlinux , 16-Дек-12 02:07 

:)

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 16-Дек-12 18:35 
> Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^

В сильно некоторых случаях может удасться отыграть немного :)

Например зипуете файл на несколько гигз состоящий из нулей. А потом зипуете такой зип. Сожмется.


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 15-Дек-12 16:05 
Ждем в ванильном и в основных дистрах!

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 15-Дек-12 19:13 
На диск тоже лучше сжатое класть. Диск сейчас узкое место, а не проц.

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено pavlinux , 15-Дек-12 21:34 
> Диск сейчас узкое место, а не проц.

Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты.



"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Led , 16-Дек-12 02:33 
>Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты.

Да. Вот только посмотри во сколько раз возросла скорость записи на диск и в память за последние 10-15 лет. Подсказка: сравнение не в пользу дисков.


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено pavlinux , 16-Дек-12 02:39 
>>Диск ВСЕГДА был узким местом.
> Подсказка: сравнение не в пользу дисков.

Эм, см выше 0:)


"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Crazy Alex , 16-Дек-12 16:43 
Ок, сейчас диск стал более узким местом.

"Для Linux представлена технология Zswap для сжатого кеширова..."
Отправлено Аноним , 16-Дек-12 18:38 
> Диск ВСЕГДА был узким местом.

Просто как-то так вышло что раньше процы были дохлее а скоростные алгоритмы сжатия не настолько развиты. По поводу чего сжатие если и применялось то не с целью выиграть в скорости а скорее место на диске сэкономить. На данный момент оно может убить 2 зайцев сразу. LZO/lz4/... могут жать с настолько зубодробильной скоростью что сжатая запись окажется быстрее за счет сокращения I/O. А уж чтение и подавно - такие алгоритмы дико быстры в распаковке. В ряде случаев они могут обогнать memcpy() за счет снижения объема читаемых данных при равном объеме записи ;)