После двух месяцев разработки Линус Торвальдс выпустил (https://lkml.org/lkml/2014/3/30/336) ядро Linux 3.14 (https://www.kernel.org/). Среди наиболее заметных улучшений: новый класс планирования задач Deadline, блочное устройство zram для хранения раздела подкачки в ОЗУ с сжатом виде, поддержка режима PVH в Xen, расширение возможностей трассировки.
В новую версию принято более 12 тысяч исправлений от почти 1400 разработчиков, размер патча - 32 Мб (изменения затронули 10.6 тысяч файлов, добавлено 606195 строк кода, удалено 265086 строк). Около 46% всех представленных в 3.14 изменений связаны с драйверами устройств, примерно 19% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 16% связано с сетевым стеком, 5% - файловыми системами и 3% c внутренними подсистемами ядра. 10.2% изменений внесено сотрудниками компании Intel, 7.3% - Red Hat, 4.4% - Linaro, 5% - Samsung, 3.3% - SUSE, 2.9% - IBM, 2.7% - Google, 2.4% - TI, 2.1% - NVIDIA, 2.0% - FOSS Outreach Program for Women, 1.8% - Huawei, 1.3% - Oracle.
Из наиболее интересных новшеств (http://kernelnewbies.org/Linux_3.14) можно отметить:
-
Память и системные сервисы
Для планировщика задач добавлена поддержка класса SCHED_DEADLINE (http://www.evidence.eu.com/sched_deadline.html), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов.Ранее доступный планировщик задач не мог обеспечить такое поведение, так как не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мкс в интервале 100 мкс) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.
- Снятие (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) ярлыка экспериментальной разработки и перенос из ветки staging в основное дерево ядра подсистемы zRAM, предназначенной для хранения раздела подкачки в памяти в сжатом виде. Суть zRAM сводится к тому, что в памяти создается блочное устройство на которое производится своппинг со сжатием. В настоящее время zRAM уже активно используется в различных потребительских устройствах, в том числе в телеприставках и портативных устройствах на базе платформы Android, ChromeOS и cyanogenmod.
- Поддержка (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) триггеров в подсистеме обработки событий трассировки, позволяющей отследить обращение к тем или иным функциям ядра. Триггеры дополняют ранее присутствующую возможность установки контрольных проверок (probe) возможностью привязки условных команд, вызываемых при срабатывании контрольной проверки. Через данные команды можно выполнять такие действия, позволяющие получить дополнительные сведения, как включение или выключение других событий трассировки или активация трассировки стека. Каждая команда может задаваться с использованием фильтра событий, позволяющего триггеру срабатывать только при нужных условиях. Например, выполнение "echo 'stacktrace:5 if bytes_req >= 65536' > /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger" приведёт к установке триггера выдающего трассировку стека для первых пяти запросов к kmalloc с размером больше 64 Кб.
- В системе контрольных проверок (userspace probes), используемой для анализа поведения выполняемых в пространстве пользователя приложений, добавлена поддержка извлечения данных из стека и памяти пользовательского процесса, а также обработка таких типов аргументов, как разыменования, битовые поля, возвращаемые функцией значения и смещения в файлах. Uprobes можно использовать для определения узких мест в производительности, накапливать отладочные данные и информацию о времени выполнения разных частей приложения в полностью прозрачном режиме, никаким образом не влияя на работу отслеживаемого процесса. Запустить и остановить сбор данных можно в любой момент, без перезапуска или модификации программы.
- В состав ядра принят набор патчей biovec (http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/Documentatio...), вносящий некоторые изменения в API блочного уровня ядра, в том числе добавляющий поддержку создания произвольных купных запросов ввода/вывода и увеличивающих эффективность работы.
- Обеспечена возможность (http://lwn.net/Articles/536363/) использования реализованной на уровне ядра системы lockdep для отладки функционирования блокировок в пространстве пользователя (в частности для выявления взаимных блокировок в многопоточных программах).
- Добавлена возможность использования системного вызова kexec() на системах с EFI BIOS. Kexec предоставляет возможность загрузки нового экземпляра ядра из уже запущенного ядра Linux, обеспечивая вариант мягкой перезагрузки, без возвращения управления в BIOS;
- Значительно переработано внутреннее устройство виртуальной файловой системы sysfs. В итоге, представлена новая подсистема "kernfs", которая может выступать в качестве основы для других ФС, похожих на sysfs. Например, планируется создать виртуальную ФС для управления cgroup.
- Реализована (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) инфраструктура компонентных подсистем ("componentized subsystems"), предназначенная для управления сложными устройствами, состоящих из нескольких взаимодействующих друг с другом более простых устройств.
- В подсистему perf events добавлена поддержка механизма учёта энергопотребления "RAPL", используемого в процессорах Intel; Добавлена (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) серия новых опций в утилиту perf.
- В экспериментальную staging-ветку добавлен используемый в платформе Android механизм распределения памяти ION (http://lwn.net/Articles/480055/), нацеленный на эффективное решение проблем с фрагментацией памяти и поддерживающий предоставление совместного доступа к буферам при помощи DMABUF;
-
Сетевая подсистема- Добавлена новая возможность "TCP autocorking", позволяющая задержать передачу небольших порций данных для объединения их в более большие пакеты, что позволяет снизить нагрузку на CPU и обеспечить более эффективную пропускную способность. Для управления новой возможностью представлен sysctl tcp_autocorking. По умолчанию поддержка tcp_autocorking включена.
- Добавлен новый ioctl вызов SIOCGHWTSTAMP, позволяющий приложениям получить текущую конфигурацию меток времени (timestamping), без внесения в неё изменений.
-
Дисковая подсистема, ввод/вывод и файловые системы
- Для файловой системы Btrfs расширен объём информации, предоставляемой через sysfs, в том числе теперь можно получить данные о доступных возможностях и использовании дискового пространства. Ранее указанные данные можно было получить через ioctl(), но sysfs гораздо удобнее для использования в скриптах или из командной строки.
- В распределённую файловую систему Ceph добавлена поддержка списков контроля доступа (ACL).
-
Виртуализация и безопасность- Интегрированы наработки (http://lwn.net/Articles/569635/) проекта KASLR (аналог ASLR для ядра) с реализацией средств рандомизации раскладки адресного пространства ядра, которые позволили увеличить стойкость ядра к н...
URL: https://lkml.org/lkml/2014/3/30/336
Новость: http://www.opennet.me/opennews/art.shtml?num=39390
zram это, конечно, хорошо
а как это, область памяти в памяти?
и зачем?
Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря. Резонный вопрос - если это из-за большой ОЗУ, то тогда зачем вообще делать своп в озу???
Вот этот для вас достаточно маленький?$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 38.40processor : 1
BogoMIPS : 38.40processor : 2
BogoMIPS : 38.40processor : 3
BogoMIPS : 38.40Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x06f
CPU revision : 0Hardware : Qualcomm MSM 8974 (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
Узким местом давно стала не числомолотилка а шина и память что на ней болтается. Поэтому при кажущейся абсурдности такого изврата профит таки получается. Распаковать блок памяти выходит быстрее чем прогнать его по шине непакованным.
Мозг у тя узкое место.Посчитай на досуге, сколько тактов проца нужно, чтоб переколбасить
в течении минуты, поток, со скоростью 6 Гб/сек. (прим. скорость шины).Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.
Собственно, благодаря таким адцким скоростям, стало выгоднее делать блейд-сервера
и кластеры, а не 1024 процессорные материнки.
Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще какой...
Ощущаете, но не понимаете, откуда он взялся. Ваше объяснение негодное. Шина тут не при чём, тут при чём скорость чтения-записи и позиционирования головок на жёстких дисках. С SSD такой проблемы нет - там уже всё упирается в скорость SATA. Придумают более быстрый интерфейс - профит от сжатого свопа в оперативке будет ещё меньше.
есть SSD с интерфейсом PCIe.
> Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще
> какой...Иди в венду ощущай. Млять, откуда вас столько выросло. Ощущают профит они... уссаца.
Вот когда ты будешь делать обсчитывать фотограмметрию для интеграции со срочным заказом на архитектурный проект и как всегда при этом не хватит твоих 64гб DDR5.. на немного.. всего на гигабайт в своп на харде залезет. Вот тогда ты начнешь волосы на седалище рвать и рассказывать себе как это ненужно, глядя как расчетное время выполнения с 6 часов превращается в 6 недель. Эксперт по детским садам.
Это чё за высер тут нарисовался - "будешь делать обсчитывать"?!Ах да, срочные заказы бывают только у лохов ибо отсутствие планирования
первый признак лоховской конторки-однодневки. Мне пох...й на лохов.
Вам же четко написали- фотограмметрия, т.е. обработка изображений. Это комплекс математических обработок большого массива данных, составляющих изображение.
Так что при чем здесь планирование. Криминалистам трупы не планируют, например...
> Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.Ты уверен что на его девайсе с ARMv7 они есть? :)
> Собственно, благодаря таким адцким скоростям, стало выгоднее делать блейд-сервера
> и кластеры, а не 1024 процессорные материнки.А диски как были слоупочными, так и остались. Поэтому своп на них - отвратителен по скорости работы. Свопиться на SSD - протрется в момент. Ну вот и пришли к компромиссному варианту - свопиться в оперативку :).
Можно подробнее?
Интересно знать, каким местом ацкие скорости PCIe и HT имеют отношение к построению кластеров.
> Интересно знать, каким местомтрехкАнальным
> Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря.Весьма зависит от того как это соотновится с I/O. Если I/O медленный, почему бы нет? :)
1). Берём легко сжимаемые данные.
2). Помещаем их в ZRAM, забив всё доступное место. Например 8 Гб при физически доступных 2 Гб.
3). Внезапно удаляем 8 Гб легко сжимаемых данных и забиваем тяжело сжимаемыми данными, например H264-видео.
4). ????
5). Kernel Panic.Ну серьёзно, зачем умещать 700 Мб в 500 Мб, если внезапно может заполниться память? Зачем вообще хранить SWAP в памяти?! И это уже традиция в Linux. То фирменную технологию Google примут в ядро, которая позволяет на гигабайтной флешке создать сто стогигабайтных файлов, потому что "У нас на GMail лишь 1% использует все свои 100 Гб почты, так нафига месту простаивать?". То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
Помнишь шутку про китайцев, которые попробовали по 1 пароль? Если каждый китаец зарегистрируется в GMail и заполнит на 100% своё место, GMail "упадёт"!
Затем, что диск - узкое место большинства систем. Ваш кэп.
>Затем, что диск - узкое место большинства систем. Ваш кэп.Но зачем? Если памяти и так хватает, то нафиг подкачку. Прям веднузятничество какой-то. Только венда умудряется использовать своп при на 80% свободной памяти.
Если памяти хватает, то и zram и swap остаются пустыми. Снова, ваш кэп.
> Но зачем? Если памяти и так хватает, то нафиг подкачку.Довольно странно использовать zRAM, если памяти хватает. А вот когда ее МАЛО, при современной мощности числокрушилок сжатие может быть шустрее чем запись на тормозной носитель. Особенно на всяких мелких девайсах типа мобилок и т.п..
Панику легко исключить резервированием достаточного дискового пространства для помещения несжатых данных. А все остальное - для скорости, как уже было сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста. В ЦОДах подавай эффективность, хоть винду ставь...
> сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
> В ЦОДах подавай эффективность, хоть винду ставь...Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте ЦОДов...
>> сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
>> В ЦОДах подавай эффективность, хоть винду ставь...
> Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте
> ЦОДов...Надежность (оно же "чтоб работало") - необходимое условие. Но не достаточное. Хотя конечно оно одно из первых обсуждается. ИМХО конечно.
> 1). Берём легко сжимаемые данные.
> 2). Помещаем их в ZRAM, забив всё доступное место. Например 8 Гб
> при физически доступных 2 Гб.
> 3). Внезапно удаляем 8 Гб легко сжимаемых данных и забиваем тяжело сжимаемыми
> данными, например H264-видео.
> 4). ????
> 5). Kernel Panic.И при чём тут сжимаемость данных? Все 8 гигабайт этого видео не потребуются одновременно - это раз. Во-вторых - они есть на диске, зачем их все грузить? Лучше читать по мере необходимости с небольшим упреждением. Ну и наконец, можно же использовать двухуровневую систему подкачки, или даже трёхуровневую - zRAM, раздел подкачки на SSD-диске, раздел подкачки на диске со шпинделем. Реже используемые данные вытесняются на более медленную систему.
>Ну серьёзно, зачем умещать 700 Мб в 500 Мб, если внезапно может заполниться память?
Медленным жёстким диском не пользоваться без необходимости - вот зачем. Когда действительно будет нехватка оперативки - что-ж, придётся воспользоваться разделом подкачки на жёстком диске.
>Зачем вообще хранить SWAP в памяти?!
Зачем дисковый кэш в памяти хранится? Чудик, ты вообще знаешь, что в Linux практически не бывает свободной, в полном смысле этого слова, оперативной памяти? Если есть свободная память, Linux будет использовать её в качестве дискового кэша, чтобы не читать с медленного жёсткого диска то, что уже раньше читалось. Всё равно она без дела простаивает.
>И это уже традиция в Linux. То фирменную технологию Google примут в ядро, которая позволяет на гигабайтной флешке создать сто стогигабайтных файлов, потому что "У нас на GMail лишь 1% использует все свои 100 Гб почты, так нафига месту простаивать?".
Вообще-то, в Unix'ах отродясь на диске место не занимается, если в него ничего не писалось. Можно открыть файл на запись, промотать 100 гигабайт и записать один байт. Файл будет иметь размер 100 гигабайт с хвостиком, но реально будет занимать на диске только объём этого хвостика. Утилиты dumpfs и restorefs - единственные, кто это свойство умеет учитывать и не тратить зря место на "магнитной ленте".
Гугель лишь изобрёл велосипед, под свои собственные нужды.
>То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
Не мифической, а очень даже реальной. СУБД может сотни раз в секунду перезаписывать одни и те же данные. Сделать сотни записей на диск или одну - есть разница?
Воинствующее невежество ты наше, потреблять от ИТ. Если ты видишь глупость, то тут обычно есть два варианта - либо это действительно глупость, либо это не глупость, а просто ты чего-то не понял. Но твой межушный ганглий до второго варианта додуматься не может и поэтому сразу бросается вопить.
>>То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
> Не мифической, а очень даже реальной. СУБД может сотни раз в секунду
> перезаписывать одни и те же данные. Сделать сотни записей на диск
> или одну - есть разница?Если СУБД сто раз за секунду перезаписала данные, они должны быть сто раз за секунду перезаписаны на диске. Логика BEGIN/COMMIT такое диктует для RDBMS, вроде как. Вернулись из COMMIT — данные ГАРАНТИРОВАННО записаны на диск.
Если RDBMS заставляют сто раз в секунду перезаписывать одно и то же, кэшированием записи на диск это не решить, и не нужно.
Вы не правы. Сжатие подкачки - это именно оно и есть. До того, как данные попадут в своп, они будут сжаты, что уменьшает количество дисковых оперций. Если памяти всё же не будет хватать - эти сжатые двнные будут вытеснены в своп. Не совсем понятно, зачем забивать память тяжкло сжимаемыми данными.
> То отложенную запись внедрят, чтобы добиться мифической
> скорости записи на диск, тогда как физически записи не было.Ну скажем SSD имеют иногда довольно ограниченные ресурсы по части перезаписи...
zram - это очень хорошо. Я его даже бэкпортировал на свое ядро 2.6.24.7 для IP приставки(blob'ы мешают перейти на что-то свежее)
А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
встроенных устройств с их погибающим от частой записи flash-ПЗУ
> А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
> встроенных устройств с их погибающим от частой записи flash-ПЗУСейчас делаю вариант патча для ядра el6, если всё пройдёт нормально - выложу на тест.
В ядре el6 zram из staging, к слову, уже имеется, однако он слишком старый.К сожалению, просто модулем - не получится, zram требует наличия аллокатора zsmalloc в mm-подсистеме ядра, в ядре el6 его нет. Поэтому только полная пересборка.
Портировать не сложно. Также модифицировать: так как в системе имелись статические буфера для видео/аудио декодеров и т.п., которые не использовались в некоторых случаях(загрузка обновлений в RAM и запись их во flash после загрузки), то был написан дополнительный allocator для модуля zram, который помещал несжимаемые данные в эти буфера.
> А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
> встроенных устройств с их погибающим от частой записи flash-ПЗУВариант для CentOS 6 тут:
http://alex-at.ru/linux/zram-c6Для ядра OpenVZ адаптировать составить труда не должно - патч тот же, только .spec и конфиг чуток подправить.
Интересно, можно ли будет хранить в сжатом виде не раздел подкачки, а, например, /var/log?
Вы хотите логи в ram держать?
Плохая идея.
К тому же для логов итак логротэйт есть. С сжатием архивов и тд.
> Вы хотите логи в ram держать?
> Плохая идея.
> К тому же для логов итак логротэйт есть. С сжатием архивов и
> тд.Некоторые виды устройств, хранят логи в RAM памяти. Обычно на таких устройствах RAM в 4 раза больше чем Flash
И что это должно доказывать?
Что syslog должен теперь (как и эти устройства) в озу всё держать?Зыж
эти устройства рассчитывают что их логи кто-то забирает.
а если не забирает, то значит и не нужны, что в общем случае тут и не рассматривается (не ведите их тогда вообще).
Если ты боишься испортить логами новый SSD диск, то совершенно зря. Тебе придётся писать логи на полной скорости винта несколько лет к ряду, чтоб его испортить. А переносить логи в память просто так это действительно плохая идея.
> на полной скорости винта несколько лет к ряду, чтоб его испортить.Ага, ЩАЗ. Типичный NAND выдерживает 1-2 тысячи записей. За год можно переписать содержимое винта явно более 1000 раз. Другое дело что мало у кого такой конский объем логов.
Сейчас все типичные SSD делают на TLC и MLC, а это 5 и 10 тысяч циклов. Нетипичные делают на SLC и это 100 000 и дорого. Ок, согласен, что про полную скорость я загнул, но логи в таких конских объёмах действительно редко пишутся и SSD на 120 Гб прослужит достаточно долго. В конце-концов тебе понадобится записать туда петабайт данных, чтоб высадить все ячейки. На современных винтах обычно указывают время до первого отказа при нормальной нагрузке и это обычно 1 200 000 часов для 120 Гб MLC (более 100 лет). Т.е. это если ты не пытаешься использовать винт на файловом сервере, например, с постоянной записью.
Пугаясь размеру ядра от релиза к релизу, хочу спросить - сколько они занимают места?
В 4мб флеша моего роутера влезает помимо ядра 3.10 еще и вебморда с бизибоксом.
Не пугайся. В винде драйвера отдельно от ядра, а здесь вместе. Поэтому сбивает с толку. Все драйвера лежат отдельно от ядра - в виде модулей (если не монолит).
-rw-r--r-- 1 root root 6533680 апр 1 07:07 kernel-3.14.0-gentoo
lz4
ну да, на дискету уже давно не влазят...
Это ядро просто обязано быть запущенным на Raspberry Pi.
Запость фичреквест на pidora.ca
а они (или кто-нибудь) дрова в меинстрим спортировали? Грег говорил, что это удивительно, что rpi-шное ведро вообще работает
А еще геометрические шейдеры для radeon 2400-4970
или нет?
ядро тут не виноватое
> Для файловой системы Btrfs расширен объём информации, предоставляемой через sysfs, в том числе теперь можно получить данные о доступных возможностях и использовании дискового пространстваОтлично. А то с аудитом у Btrfs плоховато.
c btrfs вообще всё плоховато
А.. да-да.
Не буду вам мешать общаться на "профессиональную" тему.Зыж
Ха! Павлины говоришь?
> c btrfs вообще всё плоховатоДа, только вон фэйсбучек собирается тестовый деплоймент делать, зюзя на нее переходит. Но у нас то тут мегаадмины суперэнтерпрайзов, у местных экспертов у каждого по три инсталляции размером с два фэйсбука каждая, и уж конечно они свой дистр выпускают, даже два.
Аудит вешается на vfs.
А то что вы подумали, называется отладка, профайлинг,.. всё что угодно, но точно не аудит.
(Кстати то, про что вы подумали включается при конфигурации ядра/модуля ядра)
Объясните, зачем нужен zram? Всё исключительно из-за сжатия и теоретической возможности уместить больше данных в рам?
Да. Посмотрите кто именно этим заинтересован.
В телефонах/планшетах иметь свап на ссд не всем нравится. Это уменьшает ресурс девайса (особенно когда в него хотят запихнуть железки из разряда "по-дешевле")
Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?
> Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?Сжатие, сэр. Это несколько шустрее, чем посвопаться на диск. Тратя память на своп в ZRAM, в итоге получаем свободную память за счёт сжатия того, что "высвопили".
Для устройств с flash памятью, у которой маленькое число циклов записи.
> теоретической возможности уместить больше данных в рам?Поскольку большинство содержимого RAM отлично жмется, а упаковка/распаковка RAM быстрее чем запись на тормозной диск - можно в ряде ситуаций поиметь профит.
>В DRM-модуле драйвера Nouveau добавлена поддержка GPU NVIDIA серии GK110 ( GeForce GTX 780, GTX Titan) и GK208 (GeForce 630/640).Надо же, и года не прошло. Попробовать, чтoле?
> Попробовать, чтoле?Чо, целый год на Titan копил?!
Не, целый год страдал на проприетарном драйвере. Плакал по ночам в подушку. Донатил мозелеедам во искупление греха сего.
А что будет с hibernate, если своп в раме? Я надеюсь, его не повключают везде по дефолту?
В привычном смысле Hibernate в мобильных устройствах отсутствует, связь с ОпСоС'ом хотелось бы поддерживать постоянно. :)
Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистов.
>путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистовкак и забывать, что не везде используют ванильное ядро, среди "кулхацкеров".
> Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с
> "мабилой", видимо, уже традиция среди линуховых погромистов.Нормально всё - в сжатом виде и пишется. При загрузке разжимается...
Данные "лежат" в zram до появления необходимости записать из на диск.
Использовал zram в паре с убитым диском, очень выручал.
Предлагаю SWAP делать просто файлом в tmpfs_со_сжатием. Ж)
с разморозкой!!# egrep "(ZSWAP|ZRAM)" /usr/src/.config
CONFIG_ZSWAP=y
CONFIG_ZRAM=y
# CONFIG_ZRAM_DEBUG is not set
В состав каких дистрибутивов оно войдет? Каков будет срок его жизни? Насколько больше устройств в нем поддерживается по сравнению с другими ветками ядра?
для убунты уже есть пакеты на kernel.ubuntu.com
> В состав каких дистрибутивов оно войдет? Каков будет срок его жизни?
> Насколько больше устройств в нем поддерживается по сравнению с другими ветками
> ядра?не знаю как в других дистрах, но в gentoo-patches уже полгода точно присутствует...
> полгода точно присутствует...Мюнхаузен, залогинься! Ядро 3.14 пилят менее 2 месяцев, IIRC.
Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если озу кончалось???
OOM уж больно долго думает (около 5-10минут) перед тем как убить тот или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не помогло =(
Сделать swap меньше. Пока kswapd будет способен перекидывать страницы между ram и swap, у OOM не будет причин сработать.
У меня просто 16gb, я свап вообще не врубал, думал что он влияет на OOM killer....
> У меня просто 16gb, я свап вообще не врубал,Ну и правильно. Нафиг вам своп с 16Гб?
Дык, вот поэтому его и не врубал, но каким то макаром, смог повесить систему на минут 5-10 при срабатывании OOM Killer'а Oo
> Дык, вот поэтому его и не врубал, но каким то макаром, смог
> повесить систему на минут 5-10 при срабатывании OOM Killer'а OoПросто ядро при недостатке памяти сначала сбрасывает все дисковые кэши и потом при каждом обращении к файловой системе ходит непосредственно на диск, а не в кэш. И это выглядит как подвисание, несмотря на то, что свопа в системе нет вовсе.
> Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
> озу кончалось???
> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
> или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
> помогло =(А в BSD наоборот - очень быстро :D
>> Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
>> озу кончалось???
>> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
>> или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
>> помогло =(
> А в BSD наоборот - очень быстро :DУгу при "ручном" аллокэйте - он срабатывает мгновенно, но скорее всего из-за видюхи (она юзает часть озу) он и повесился на это время. (Видюха встроенная Intel GMA)
> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
> или иной процесс,Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и выюзавшая программа пристрелились весьма резво.
>> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
>> или иной процесс,
> Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как
> раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и
> выюзавшая программа пристрелились весьма резво.Похоже это из-за того что у меня в то время была запущена игрушка и она начала аллокейтить озу в видюхе, в то время когда кончалась озу и вот результат .. (видюха встроенная intel gma)
Что значит "сильные подвисания"? Зависание оно или есть, или его нет. Просто как немного беременная.
как всегда обделили драйвера для n7260 wifi (обещали полную поддержку в 14 ядре)
Это ж блин Пи ядро :)
> Это ж блин Пи ядро :)точно же! щас в грубе версию поправлю :)
> Это ж блин Пи ядро :)Надо так - π !
tcp_autocorking - предохранитель от разгона интернета! :)
Бэкпорт для CentOS 6 тут:
http://alex-at.ru/linux/zram-c6
> Бэкпорт для CentOS 6 тут:
> http://alex-at.ru/linux/zram-c6Бэкпорт ZRAM, конечно же.
> Бэкпорт для CentOS 6 тут:А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
а еще раньше валялось ненужное под именем compcache на гуглекоде.Какие-то вы тормоза. :D
> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,На самом деле для специфичных применений вполне нужное, но из staging бэкпортировать было лениво.
>> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
> вполне нужное, но из staging бэкпортировать было лениво./lib/modules/2.6.32-279.el6.x86_64/kernel/drivers/staging/zram/zram.ko
?? П-поясни? Чем твой "бэкпорт" лучше /staging?
> ?? П-поясни? Чем твой "бэкпорт" лучше /staging?Пока драйвер находился в staging - он не считался готовым к использованию. Между 3.13 и 3.14 в него, собственно, внесено некоторое число изменений. Это раз.
Если сравнивать со staging из штатного ядра RHEL - то там совсем тихий ужас. Во-первых, используется старый, как говно мамонта, вариант. Во-вторых, там используется другой, "навесной" аллокатор для сжатых страниц.
> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нyжное.,Пока ты каркал, это замайнлайнили. Прокаркал ты свой тезис.
Лошара ты малолетняя. Пока ты ф школе азбуку учил, я эту куету вдоль и поперёк изучил.
Хрень это не нужная. Для ИБД можешь заюзать ZSWAP
> Оно с ядра 2.6.33 валяется никому не нужное.,Использовано в http://altlinux.org/LTSP (с 2.6.22), для тонких клиентов бывает крайне полезно -- led@ по этому поводу вкручивал статистику, набранную отправляли разработчикам.
Апдейт бэкпорта ZRAM в ядро CentOS 6: http://alex-at.ru/linux/zram-c61. Версия ZRAM обновлена до текущей в мейнстримном ядре (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git).
Изменения:
а) Поддержка Discard (TRIM) для ZRAM
б) Поддержка многопоточного сжатия (max_comp_streams) для ZRAM
в) Поддержка схемы компрессии LZ4 (comp_algorithm) для ZRAM и crypto
2. Версия ядра CentOS 6 обновлена до 2.6.32-431.17.1
> изменений внесено сотрудниками компании Intel, 7.3%AMD пофиг на Linux, интересно как там дела с 3DNow!
+ FMA; 3DNowExt
>> изменений внесено сотрудниками компании Intel, 7.3%
> AMD пофиг на Linux, интересно как там дела с 3DNow!Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.
>>> изменений внесено сотрудниками компании Intel, 7.3%
>> AMD пофиг на Linux, интересно как там дела с 3DNow!
> Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.<NOTROLL>Я не совсем ронял, почему они отказались от 3dnow% ?</NOTROLL>
Инструкции не пользовались особой популярностью. Фактически большинство из них являлось подмножеством SSE (с чуть другими особенностями работы с регистрами и сохранения значений регистров). Небольшие преимущества 3DNow окончательно исчезли с выходом SSE3, в котором стали возможны последние вещи, которые до этого делались более эффективно в 3DNow.Остались одни недостатки: самих инструкций и возможностей намного меньше, чем во всех SSE к этому моменту, регистры разделяются с FPU, из-за чего невозможно использовать одновременно 3DNow и FPU инструкции (ср. с -mfpmath=sse+387 в gcc, когда для скорости используются одновременно FPU и SSE инструкции для FP-вычислений), а все современные процессоры, поддерживающие 3DNow уже поддерживали последние версии SSE, и смысл использовать 3DNow в новых программах пропал - зачем, если с SSE можно сделать лучше, в том числе на AMD'шных процессорах?
Осталась только поддержка старого софта, но т.к. софта, который строго требовал 3DNow и не работал бы с SSE или без мультимедийных расширений не было, стало возможным убрать поддержку инструкций из новых процов, ничего не сломав.
> AMD пофиг на Linux,В чем это выражается? Процы и чипсеты поддерживаются, GPU пилят ударными темпами. А ничего иного амд вроде и не выпускает так по крупному...
А ещё Линус Торвальдс заявил об изменении нумерации сборок: следующая - 3,141, потом - 3,1415 и далее. Релиз "Тäydellisyys" выйдет после полного завершения разработки.
Лавры Кнута спать спокойно не дают?