форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для Linux представлена технология сжатого кеширования раздел..."	+/–
Сообщение от opennews (ok) on 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 Новость: https://www.opennet.ru/opennews/art.shtml?num=35610
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
Сообщение от VecH (ok) on 14-Дек-12, 22:11
в прошивках Андроид-а для HTC HD2 еще в прошлом году появились функции, которые позволяли задействовать zRam (сжатый swap в RAM)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Для Linux представлена технология сжатого кеширования раздел..."	+2 +/–
	Сообщение от rshadow (ok) on 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
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Для Linux представлена технология сжатого кеширования раздел..."	+2 +/–
	Сообщение от rshadow (ok) on 14-Дек-12, 22:39
	Модуль ядране забываем включить /etc/modules: zram zram_num_devices=1
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от DannyBoy (ok) on 14-Дек-12, 22:51
	Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	12. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 14-Дек-12, 23:13
	> Есть ли преимущества по сравнению с обычным свопом и чувствуются ли они на глаз? На некоторых девайсах - все шансы ощутить. На всяких там телефонах с медленным флешом на который активно свопиться беспонтово - весьма интересный вариант.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "Для Linux представлена технология сжатого кеширования раздел..."	–2 +/–
	Сообщение от DannyBoy (ok) on 14-Дек-12, 23:18
	Ну учитывая, что написано про приличное использование проца, а средний ARM не есть гуд для мат. вычислений, то в лучшем случае телефоны будут мало работать, а в худшем - жарить перепелиные яйца на корпусе. Так что сложно придумать использование сей технологии.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Для Linux представлена технология сжатого кеширования раздел..."	+11 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 00:09
	> средний ARM не есть гуд для мат. вычислений Во первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом. Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет. В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Для Linux представлена технология сжатого кеширования раздел..."	–2 +/–
	Сообщение от DannyBoy (ok) on 15-Дек-12, 00:17
	>Во первых, современный ARM нынче спокойно затыкает типовой атом вообще не моргнув глазом. Какую-нибудь заглушку n2600 может быть, но n450-455 может какой-нибудь cortex-a15, но они многоядерные, хотя с конвейером помутили хорошо взамен большего потребления. >Во вторых, при скоростном сжатии никаких особо хитрых вычислений нет. Зато сжимать нужно достаточно много, и тут могут быть подтормаживания из-за "большой очереди". >В третьих, увеличение скорости работы системы в целом - вопрос того что дороже: I/O или циклы процессора. В ряде систем I/O с флешкой и/или SD картой является очень дорогим процессом который сам клинит проц по полной. В свете этого возможет парадокс когда сжатие повысит скорость работы, сократив объем медленного и грузящего систему I/O. Полностью согласен. Кстати, это довольно частое явление, что приходится выбирать чем жертвовать - цпу или памятью.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Для Linux представлена технология сжатого кеширования раздел..."	+4 +/–
	Сообщение от Аноним (??) on 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.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	26. "Для Linux представлена технология сжатого кеширования раздел..."	–2 +/–
	Сообщение от DannyBoy (ok) on 15-Дек-12, 10:16
	>Ну так процесс идет, A15-е уже временами показывают чуть ли не половину от скорости i3/i5 в ряде бенчей. Тут уже нужны пруфы, ибо уж больно громкие слова. К тому же помню находил информацию, что на уровне серверов, энергоэффективность Зионов идёт выше чем у ARM-кластеров. Если интересно, то могу поискать. >Кстати и обычные механические диски могут ускориться при сжатии. LZO на современном проце в состоянии жать быстрее чем 150Мб/сек Это да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода. >А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM. Но для телефонов это бессмысленно. : )
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	36. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 15-Дек-12, 17:41
	> Тут уже нужны пруфы, ибо уж больно громкие слова. Идете на тот же фороникс и смотрите бенчи армов между собой и vs x86, например. Там такого счастья - есть. > К тому же помню находил информацию, что на уровне серверов, энергоэффективность > Зионов идёт выше чем у ARM-кластеров. Наверное именно поэтому нынче ARM в сервера вдарился, ага. Всякие там Calxeda и прочие что-то полезли новый рынок окучивать, а с выходом в массы 64-битного ARM с виртуализацией и прочая интелу имхо будет весело :) > Если интересно, то могу поискать. Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря о том сколько независимых серверов упихивается в 1 стойку, какой TDP проца называется и прочая. > Это да, ибо большинство домашних компов - многоядерные, с хорошей оптимизацией кода. Ну а в мобилках всяких все пропорционально хилее. И I/O - тоже. Поэтому ARMу из смарта и не требуется 150 мб/сек выжимать. Кстати если вы вдруг не заметили, нынче аж 8-ядерные процы для планшетов и мобил собираются клепать. >>А данном случае это облегчение жизни относительно тормозному I/O путем усложнения жизни процу и RAM. > Но для телефонов это бессмысленно. : ) Напротив, там обычно очень тормозное I/O, так что в смартах и планшетах у технологии есть все шансы себя проявить. Вон там выше народец даже упоминает конкретные примеры юзежа подобных по смыслу технологий.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	39. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 15-Дек-12, 17:51
	> Давайте, а то calxeda и им подобные утверждают ровно обратное. Не говоря > о том сколько независимых серверов упихивается в 1 стойку, какой TDP > проца называется и прочая. Calxeda & co будто бы отчаянно избегают называния цифр по энергоэффективности на операцию -- скажем, "обслужить миллион запросов".  Тесты, которые на подручном оборудовании делали коллеги, показали бОльшую энергоэффективность того же C2Q перед A8 на обслуживании DNS-запросов, ЕМНИП. На ARM может получиться куда более осмысленно предоставить _физически_ отдельную железку человеку/задачке.  Но вот с ваттами под нагрузку тут лучше не судить опрометчиво.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	46. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Romik (??) on 15-Дек-12, 22:11
	А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Romik (??) on 15-Дек-12, 22:13
	> А давайте ещё про всякие Power'ы, SPARK'и и Itanium'ы поговорим :) SPARC'и
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	57. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 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 схемы под нагрузкой жрут прямо пропорционально размеру элемента, так что сравнивать в указанном контексте имеет смысл как минимум ядра отлитые по более-менее одинаковым нанометрам.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	63. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Michael Shigorin (ok) on 17-Дек-12, 02:42
	> 1) А как все это мерялось? A8 - сферическое ядро в вакууме. > Конкретные инкарнации изрядно отличаются по свойствам. Понимаю, но даже не помню, какая именно это борда была -- надо уточнить, сейчас это неудобно (возможно, i.MX53). > 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей. Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов. > А на холостое потребление [...] И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :) > 4) У интела есть еще и обвязка которая жрет немеряно. Мощности которую > жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :). Угу, помню и двадцативаттные контроллеры FBDIMM...
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	64. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 17-Дек-12, 17:25
	> Понимаю, но даже не помню, какая именно это борда была -- надо > уточнить, сейчас это неудобно (возможно, i.MX53). Да я этом к тому что миллион запросов сам по себе - нечто сферическое и в вакууме. Роялит еще и время за которое он приехал. При высокой интенсивности запросов интел может попытаться скрасить немеряное потребление в холостом режиме ломовой производительностью. При низкой - ARM на полной загрузке будет жрать в 10 раз меньше чем интел на холостом ходу. Интел сделал нулевую с точки зрения окружающих работу а сожрал больше. Забавно, да? :) >> 2) Кроме того, такое сравнение допускает что сервер прогружен на 100% возможностей. > Т.е. что это тот самый сервер, а не просто нерациональное использование ресурсов. Идеально прогрузить сервер на 100% задача нетривиальная. Даже в всепланетном масштабе потребление ресурсов колеблется например в зависимости от времени суток. Так что или сервак зашьется в час пик или будет недогружен когда все дрыхнут. Ну и вообще. Надо вот кому-то днс. Может он и не генерит миллионы запросов но не хочет зависеть от закидонов сторонних серваков, хочет свою "локалочную" DNS зону и прочая. Вполне валидное и даже типовое желание. ARM в этом плане может смотреться любопытно, т.к. фундаментально меньше жрет, занимает мизер места, а миллион запросов ему присылать будут достаточно долго :) > И всё-таки в очередной раз (sic!) прошу освоить хотя бы интрапостовую дедупликацию :) Ну да :) >> жрет чипсет x86 и прочая обвязка хватит еще нескольким ARM :). > Угу, помню и двадцативаттные контроллеры FBDIMM... Да собственно у интеля чипсеты вообще холодностью не отличаются. Да и у AMD. Какие-то потуги в этом направлении видны только в атомах. Которых ARM нынче обставляют даже в производительности. Ну им то не надо таскать вагон сложной системной логики с элементами легаси барахла.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	25. "Для Linux представлена технология сжатого кеширования раздел..."	+2 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 08:57
	Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работу какого-нибудь генератора не очень плотных объемных данных с выводом даже на диск с быстрым SATA, не то, что на флешку.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	37. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 15-Дек-12, 17:42
	> Да в общем-то это никакой не парадокс. "| gzip" иногда ускоряет работу Очень уж иногда, ибо 2-стадийный LZ+Huffman, который по определению не будет чемпионом скорости. Быстрые алгоритмы обычно являют собой максимально простой и шустрый LZ, такой может разогнаться до весьма убедительных величин.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	45. "Для Linux представлена технология сжатого кеширования раздел..."	–1 +/–
	Сообщение от Admin1 on 15-Дек-12, 21:46
	вот насчет атома не могу сказать, но eepc700 (проц celeron 600mzh ram 512) работает под андроидом 4 шустрее чем rockchip2819 1Ghz + 1G ram про батарейку молчу да рокчип меньше ее  жрет
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	6. "Для Linux представлена технология сжатого кеширования раздел..."	+5 +/–
	Сообщение от Просто прохожий on 14-Дек-12, 22:50
	zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство. zram - сжатое блочное устройство в памяти. Работают на разных уровнях.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	50. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Led (ok) on 16-Дек-12, 02:26
	>zswap - технология сжатия данных, предназначенных для своппинга, перед их сбросом на блочное устройство. >zram - сжатое блочное устройство в памяти. ...а также может выступать в качестве компрессирующего прокси для свопа на диске.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 14-Дек-12, 23:09
	> zRam Написано же - не путайте. Суть похожая но реализация весьма разная.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Для Linux представлена технология сжатого кеширования раздел..."	–6 +/–
Сообщение от 3draven on 14-Дек-12, 22:42
Я вот, то же подумал...боян же...не? zram был давненько и в чем разница? Можно было и tmpfs заюзать ранее. zram я пользовался года полтора наверное, потом памяти до 8Гб нарастил и забил как то на нее. Нипонятно мне.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Для Linux представлена технология сжатого кеширования раздел..."	–4 +/–
	Сообщение от rshadow (ok) on 14-Дек-12, 22:50
	анналогично =)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "Для Linux представлена технология сжатого кеширования раздел..."	+7 +/–
	Сообщение от Аноним (??) on 14-Дек-12, 23:16
	> анналогично =) Может не обязательно публично тупить на форуме и демонстрировать безграмотность? Это вас обоих касается :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	54. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-12, 09:23
	Явно же шпилька со стороны Привидения была, мистер урезониватель )
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

8. "Для Linux представлена технология сжатого кеширования раздел..."	–1 +/–
Сообщение от Нанобот on 14-Дек-12, 22:52
помню, была похожая программа для windows 3.1, qemm называлась
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Andrey Mitrofanov on 14-Дек-12, 22:55
	> помню, была похожая программа для windows 3.1, qemm называлась Нет, 4dos.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
Сообщение от 3draven on 14-Дек-12, 23:10
Прога была 4дос, а запускался с нее виндус, когда она была в config.sys залита и autoexec.bat :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Для Linux представлена технология сжатого кеширования раздел..."	+3 +/–
Сообщение от YetAnotherOnanym (ok) on 14-Дек-12, 23:16
Только, наверное, не совсем правильно называть это "кэшированием раздела подкачки".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Для Linux представлена технология сжатого кеширования раздел..."	–1 +/–
	Сообщение от pro100master (ok) on 15-Дек-12, 01:16
	правильно. Это скорее менеджер сжатых страниц с сомнительной областью применения. В упомянутых выше мобильных девайсах и так сильная нехватка процессорной мощности, что упаковка-распаковка там лишняя, в серверах/станциях память не такой ресурс, на котором экономят. Остаются только нетбуки/ноуты с с быстрым SSD, которым тоже, в общем то по-барану )
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	23. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 08:37
	> выше мобильных девайсах и так сильная нехватка процессорной мощности, Мощность проца которая тратится на работу с контроллером SD карты или NAND флеша может спокойно перевесить затраты на сжатие.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	32. "Для Linux представлена технология сжатого кеширования раздел..."	–3 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 15:19
	наоборот
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	38. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 15-Дек-12, 17:44
	> наоборот И в скольких девайсах вы это меряли? У меня вот есть девайс с столь медленным I/O что при записи в флеш он упирается в ... 100% CPU usage. Ежику понятно что у легкого сжатия там все шансы скостить нагрузку.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

19. "Для Linux представлена технология сжатого кеширования раздел..."	–6 +/–
Сообщение от sasa (??) on 15-Дек-12, 02:33
> Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее > compcache), при которой в памяти создается блочное устройство на которое производится > своппинг со сжатием. Так чего тут путать - и то и дугое абсолютно бесполезная херня.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от ILYA INDIGO (ok) on 15-Дек-12, 04:10
	Для ПК на x86_64 с 4Гб+ оперативой согласен, но для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	27. "Для Linux представлена технология сжатого кеширования раздел..."	–5 +/–
	Сообщение от sasa (??) on 15-Дек-12, 10:29
	> Для ПК на x86_64 с 4Гб+ оперативой согласен Еще бы не согласиться - греть воздух вместо того чтобы сбалансированно подбирать железо > для всяких смартфонов, планшетников и прочих ARM-ок вполне может сгодиться там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовали в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают, к тому же другие скоростные интерфейсы типа sata или ddr mmc давно уже не редкость на армах
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	40. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 17:55
	> там есть контроллеры NAND на скоростной шине так вот лучше бы поддержку DMA реализовали Простите, уже выпущена туева хуча чипов. Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN. > в ФС - и jffs2 и ubufs компрессию "на лету" уже поддерживают, При том - IIRC там довольно тормозной zlib. > к тому же другие скоростные интерфейсы типа sata > или ddr mmc давно уже не редкость на армах Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает. А механические диски не любят seek. А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда. А также дорого и жруче.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	55. "Для Linux представлена технология сжатого кеширования раздел..."	–3 +/–
	Сообщение от sasa (??) on 16-Дек-12, 16:15
	>  Они такие какие есть. Если при прочих равных удается выжать больше - EPIC WIN. вот ты горе-аналитик, такие как ты и разрабатывают Linux, головкой своей подумай что лучше - копировать за счет процессора или за счет контроллера DMA. > При том - IIRC там довольно тормозной zlib неповезло вам - у меня lzo там > Они конечно не редкость, но в мобилах и планшетах как вы понимаете sata никто не юзает. но там ставят eMMC с DDR > А чипы флеша просто тормозные на запись. А ставить массив параллельно работающих чипов флеша как в SSD для ускорения процесса в телефонах тупо некуда ты хотя бы uSD видел (для справки там NAND внутри с аппартаным контроллером) ? чего и куда некуда
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	58. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 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. По поводу чего производительность будет более другой.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	62. "Для Linux представлена технология сжатого кеширования раздел..."	–1 +/–
	Сообщение от sasa (??) on 16-Дек-12, 22:25
	> Хотя извращенцев которые бы свопились на файл в JFFS я все-таки не встречал. Я вообще не встречал чтобы на ARM использовали swap - поэтому говорю что это бесполезные затеи, а если тебе так нужно - можно свопиться в файл на быстром носителе типа nand. > Да, там NAND и контроллер. Но это не значит что там впихнут 16 чипаков NAND вкалывающих параллельно и топовый контроллер как в SSD. ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	65. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 17-Дек-12, 17:34
	> Я вообще не встречал чтобы на ARM использовали swap Зато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает. Например в том же N900 все это есть. И работает довольно так себе. Такие технологии имеют все шансы это улучшить. > - поэтому говорю что это бесполезные затеи, а если тебе так нужно - можно > свопиться в файл на быстром носителе типа nand. Не такой уж он и быстрый, а в некоторых железяках еще и проц грузит. И еще вопрос на что циклов больше уйдет - на скоростное сжатие или окучивание контроллера NAND в конкретной системе. > ты уже наконец погугли что такое eMMC а то все какую херню несешь про ssd. Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты памяти, только в виде чипа.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	66. "Для Linux представлена технология сжатого кеширования раздел..."	–1 +/–
	Сообщение от sasa (??) on 18-Дек-12, 12:58
	> Зато это встречал я. На NAND, кстати. И мне совершенно не понравилось как это работает. > Например в том же N900 все это есть. Правильно ли я понял что их "заводская" прошивка штатно использует swap ? Если это так - я не удивлен что их там разогнали к херям :) > Я в курсе что это такое. Это контроллер веаринга и флеха в одном корпусе. А-ля карты > памяти, только в виде чипа. Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	67. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
	Сообщение от Аноним (??) on 20-Янв-13, 22:01
	> Правильно ли я понял что их "заводская" прошивка штатно использует swap ? Да, для возможности запускать больше программ в ограниченных ресурсах. То что своп на флеше может неплохо работать - было замечено юзерами еще Nokia 770. Они стали делать свопы на картах. Нокия пошла навстречу и в N800/810 сие было сделано опционально, а в N900 и вовсе по дефолту активировано. Просто на те поры нокия умела делать не более 256Мб RAM, а это не то чтобы совсем мало, но достаточно душно для реально многозадачного девайса. На котором натурально хочется запустить кучу всего. Ну там браузер, аську, плеер, почтарь, еще кучу всего. > Если это так - я не удивлен что их там разогнали к херям :) Разогнал их гражданин элоп-остолоп сугубо потому что они очень уж мешались его винде горбатой. > Чтобы быть КО не надо что-то знать, а вообще скорость записи у них в разы выше чем у обычных карт памяти. Как бы еще от контроллера SoC зависит и прочая. У омапа в целом на том же N900 скорость не вызывает отпадение челюсти, например. Но своп там не так уж бесполезен т.к. seek time небольшой. Затыкаться оно начинает когда памяти очень грубо не хватает и рабочий набор перестал лезть в оперативку.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	24. "Для Linux представлена технология сжатого кеширования раздел..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-12, 08:37
	> Так чего тут путать - и то и дугое абсолютно бесполезная херня. Ну ты так и скажи что ты это видел только на картинке, а дальше писюка с ...цать гигз оперативы - не видишь.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Для Linux представлена технология Zswap для сжатого кеширова..."	+2 +/–
Сообщение от Loooooker (ok) on 15-Дек-12, 05:31
Сплошные упоминания в новостях про нововведения в 3.8. Похоже, тот еще торт будет! Главное не ставить все это добро сразу в продакшн ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Для Linux представлена технология сжатого кеширования раздел..."	+/–
Сообщение от Michael Shigorin (ok) on 15-Дек-12, 11:29
> "huge zero_page" Думаю, лучше почитать здесь, чем на форониксе: http://lwn.net/Articles/517465/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
Сообщение от psevdozebra on 15-Дек-12, 12:43
Похоже скоро будем ждать аппаратных решений
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от Crazy Alex (ok) on 15-Дек-12, 17:30
	ну его на фиг, такое - это ж маркетолухи такого понапишут - не поймёшь,сколько реально памяти в железке... Нет уж, мне разных даблспейсов хватило в своё время
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

30. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
Сообщение от Аноним (??) on 15-Дек-12, 13:02
>Примечание: не следует путать Zswap с похожей по смыслу технологией zRAM (ранее compcache), при которой в памяти создается блочное устройство на которое производится своппинг со сжатием. Им бы названиями поменяться.;d
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Для Linux представлена технология Zswap для сжатого кеширова..."	–2 +/–
Сообщение от Аноним (??) on 15-Дек-12, 13:55
А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от pavlinux (ok) on 15-Дек-12, 17:29
	тогда наступит сингулярность
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	41. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от Аноним (??) on 15-Дек-12, 17:58
	> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM? Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая конфигурация для этого нужна.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	43. "Для Linux представлена технология Zswap для сжатого кеширова..."	–1 +/–
	Сообщение от pavlinux (ok) on 15-Дек-12, 21:32
	>> А вот интересно, а что если заюзать вот этот Zswap вмcете с ZRAM? > Подобные извращения рассмотрены в списке рассылки с прикидками что получится и какая > конфигурация для этого нужна. Как вариант - плющить данные на лету легким режимом xz, и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	51. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от Led (ok) on 16-Дек-12, 02:31
	>Как вариант - плющить данные на лету легким режимом xz, xz эффективен на больших размерах блока, а не на блоках размером в страницу.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	59. "Для Linux представлена технология Zswap для сжатого кеширова..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-12, 18:16
	> Как вариант - плющить данные на лету легким режимом xz, > и отправлять в ZRAM, как отложенную запись, доплющиватся хардкорным LZMA. Павлин, xz это и есть LZMA, просто у остроконечников и тупоконечников как обычно нет единства насчет того в каком формате сжатый поток оформлять. Это единственное отличие в всех этих подвидах, сам LZMA лежащий в их основе - одинаковый :)
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	48. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от kai (??) on 16-Дек-12, 01:28
	Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	49. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от pavlinux (ok) on 16-Дек-12, 02:07
	:)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	60. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от Аноним (??) on 16-Дек-12, 18:35
	> Толку не будет: попробуйте повторно архивировать архив. Я когда-то пробовал ^_^ В сильно некоторых случаях может удасться отыграть немного :) Например зипуете файл на несколько гигз состоящий из нулей. А потом зипуете такой зип. Сожмется.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

33. "Для Linux представлена технология Zswap для сжатого кеширова..."	–1 +/–
Сообщение от Аноним (??) on 15-Дек-12, 16:05
Ждем в ванильном и в основных дистрах!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Для Linux представлена технология Zswap для сжатого кеширова..."	+1 +/–
Сообщение от Аноним (??) on 15-Дек-12, 19:13
На диск тоже лучше сжатое класть. Диск сейчас узкое место, а не проц.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от pavlinux (ok) on 15-Дек-12, 21:34
	> Диск сейчас узкое место, а не проц. Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	52. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от Led (ok) on 16-Дек-12, 02:33
	>Диск ВСЕГДА был узким местом. Хуже диска, только диски на USB и COM-порты. Да. Вот только посмотри во сколько раз возросла скорость записи на диск и в память за последние 10-15 лет. Подсказка: сравнение не в пользу дисков.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Для Linux представлена технология Zswap для сжатого кеширова..."	+/–
	Сообщение от pavlinux (ok) on 16-Дек-12, 02:39
	>>Диск ВСЕГДА был узким местом. > Подсказка: сравнение не в пользу дисков. Эм, см выше 0:)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	56. "Для Linux представлена технология Zswap для сжатого кеширова..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 16-Дек-12, 16:43
	Ок, сейчас диск стал более узким местом.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	61. "Для Linux представлена технология Zswap для сжатого кеширова..."	+2 +/–
	Сообщение от Аноним (??) on 16-Дек-12, 18:38
	> Диск ВСЕГДА был узким местом. Просто как-то так вышло что раньше процы были дохлее а скоростные алгоритмы сжатия не настолько развиты. По поводу чего сжатие если и применялось то не с целью выиграть в скорости а скорее место на диске сэкономить. На данный момент оно может убить 2 зайцев сразу. LZO/lz4/... могут жать с настолько зубодробильной скоростью что сжатая запись окажется быстрее за счет сокращения I/O. А уж чтение и подавно - такие алгоритмы дико быстры в распаковке. В ряде случаев они могут обогнать memcpy() за счет снижения объема читаемых данных при равном объеме записи ;)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема