The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз ядра Linux 3.14. Обзор новшеств

31.03.2014 08:18

После двух месяцев разработки Линус Торвальдс выпустил ядро Linux 3.14. Среди наиболее заметных улучшений: новый класс планирования задач Deadline, блочное устройство zRAM для хранения раздела подкачки в ОЗУ в сжатом виде, поддержка режима PVH в Xen, поддержка триггеров в системе трассировки, средства для отладки блокировок в пространстве пользователя, планировщик пакетов PIE, механизм защиты KASLR (рандомизация памяти ядра), выделение из sysfs подсистемы kernfs, из Android перенесена система распределения памяти ION.

В новую версию принято более 12 тысяч исправлений от почти 1400 разработчиков, размер патча - 39 Мб (изменения затронули 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.

Из наиболее интересных новшеств можно отметить:

  • Память и системные сервисы
    • В планировщике задач обеспечена поддержка класса SCHED_DEADLINE, реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора задачи из очереди ожидающих процессов, наиболее близкой к истечению крайнего расчётного времени (deadline). SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов.

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

    • Снятие ярлыка экспериментальной разработки и перенос из ветки staging в основное дерево ядра подсистемы zRAM, предназначенной для хранения раздела подкачки в памяти в сжатом виде. Суть zRAM сводится к тому, что в памяти создается блочное устройство на которое производится своппинг со сжатием. В настоящее время zRAM уже активно используется в различных потребительских устройствах, в том числе в телеприставках и портативных устройствах на базе платформы Android, ChromeOS и Cyanogenmod.
    • Поддержка триггеров в подсистеме обработки событий трассировки, позволяющей отследить обращение к тем или иным функциям ядра. Триггеры дополняют ранее присутствующую возможность установки контрольных проверок (probe) средствами привязки условных команд, вызываемых при срабатывании контрольной проверки. Через данные команды можно выполнять действия, позволяющие получить дополнительные сведения, такие как включение или выключение событий трассировки или выполнение трассировки стека. Каждая команда может задаваться с использованием фильтра событий, позволяющего триггеру срабатывать только при нужных условиях. Например, выполнение "echo 'stacktrace:5 if bytes_req >= 65536' > /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger" приведёт к установке триггера, выдающего трассировку стека для первых пяти запросов к kmalloc с размером больше 64 Кб.
    • В системе контрольных проверок uprobes (userspace probes), используемой для анализа поведения выполняемых в пространстве пользователя приложений, добавлена поддержка извлечения данных из стека и памяти пользовательского процесса, а также обработка таких типов аргументов, как разыменования, битовые поля, возвращаемые функцией значения и смещения в файлах. Uprobes можно использовать для определения узких мест в производительности, накапливать отладочные данные и информацию о времени выполнения разных частей приложения в полностью прозрачном режиме, никаким образом не влияя на работу отслеживаемого процесса. Запустить и остановить сбор данных можно в любой момент, без перезапуска или модификации программы.
    • Обеспечена возможность использования реализованной на уровне ядра системы lockdep для отладки функционирования блокировок в пространстве пользователя (в частности, для выявления взаимных блокировок в многопоточных программах).
    • В состав ядра принят набор патчей biovec, вносящий некоторые изменения в API блочного уровня ядра, в том числе добавляющие поддержку создания произвольных крупных запросов ввода/вывода и увеличивающих эффективность работы.
    • Добавлена возможность использования системного вызова kexec() на системах с EFI BIOS. Kexec предоставляет возможность загрузки нового экземпляра ядра из уже запущенного ядра Linux, обеспечивая вариант мягкой перезагрузки, без возвращения управления в BIOS.
    • Значительно переработано внутреннее устройство виртуальной файловой системы sysfs. В итоге, представлена новая подсистема "kernfs", на которой теперь базируется sysfs и которая может выступать в качестве основы для других виртуальных ФС. Например, планируется создать виртуальную ФС для управления cgroup.
    • Реализована инфраструктура компонентных подсистем ("componentized subsystems"), предназначенная для управления сложными устройствами, состоящих из нескольких взаимодействующих друг с другом более простых устройств.
    • В подсистему perf events добавлена поддержка механизма учёта энергопотребления "RAPL", используемого в процессорах Intel. Добавлена серия новых опций в утилиту perf.
    • В экспериментальную staging-ветку добавлен используемый в платформе Android механизм распределения памяти ION, нацеленный на эффективное решение проблем с фрагментацией памяти и поддерживающий предоставление совместного доступа к буферам при помощи DMABUF.
  • Сетевая подсистема
    • Добавлен новый планировщик пакетов PIE (Proportional Integral controller Enhanced), созданный в рамках инициативы по борьбе с негативным влиянием промежуточной буферизации пакетов (Bufferbloat) сетевым оборудованием. PIE позволяет поддерживать на заданном уровне среднюю величину задержек для пакетов в очереди. В процессе оценки эффективности работы PIE было выявлено, что алгоритм способен в обеспечить минимальную задержку и высокий уровень утилизации пропускной способности линка при возникновении различных видов перегрузки.
    • Добавлена новая дисциплина организации работы очередей пакетов "heavy-hitter filter" (HHF qdisc), пытающаяся отделять мелкие потоки от больших и помещать большие потоки в отдельную очередь с пониженным приоритетом. Использование HHF позволяет снизить влияние интенсивных передач на критичные к задержкам виды трафика.
    • Добавлена новая возможность "TCP autocorking", позволяющая задержать передачу небольших порций данных для объединения их в более большие пакеты, что позволяет снизить нагрузку на CPU и обеспечить более эффективную пропускную способность. Для управления новой возможностью представлен sysctl tcp_autocorking. По умолчанию поддержка tcp_autocorking включена.
    • Для подсистемы BPF (Berkeley Packet Filter) представлены две новые утилиты, работающие в пространстве пользователя: отладчик и простая реализация ассемблера.
    • Добавлен новый ioctl вызов SIOCGHWTSTAMP, позволяющий приложениям получить текущую конфигурацию меток времени (timestamping), без внесения в неё изменений.
    • Улучшена реализация стека Bluetooth Low Energy: расширено число протоколов, который могут использоваться в режиме низкого энергопотребления Bluetooth, добавлена поддержка эмуляции 6LoWPAN, обеспечена обработка привязанных к соединениям каналов.
  • Дисковая подсистема, ввод/вывод и файловые системы
    • Для файловой системы Btrfs расширен объём информации, предоставляемой через sysfs, в том числе теперь можно получить данные о доступных возможностях и использовании дискового пространства. Ранее указанные данные можно было получить через ioctl(), но sysfs гораздо удобнее для использования в скриптах или из командной строки.
    • В распределённую файловую систему Ceph добавлена поддержка списков контроля доступа (ACL).
  • Виртуализация и безопасность
    • Интегрированы наработки проекта KASLR (аналог ASLR для ядра) с реализацией средств рандомизации раскладки адресного пространства ядра, которые позволили увеличить стойкость ядра к некоторым видам атак, эксплуатирующих уязвимости в ядре. KASLR уже успешно используется для повышения безопасности Chrome OS.
    • Обеспечена возможность сборки ядра с включением улучшенного режима защиты от переполнения стека "-fstack-protector-strong", который появится в GCC 4.9. Сборка в режиме "-fstack-protector-strong" позволяет обеспечить защиту от переполнения стека в большем числе функций ядра, удержав при этом связанные с дополнительной проверкой накладные расходы на приемлемом уровне.
    • В гипервизор Xen добавлена поддержка режима PVH для гостевых систем, который комбинирует элементы режимов паравиртуализации (PV) и полной виртуализации (HVM). В режиме PVH с одной стороны применяется полная виртуализация на уровне ограничения привилегированных инструкций, изоляции системных вызовов и виртуализации таблиц страниц памяти, но с другой стороны используются методы паравиртуализации для ввода/вывода, обработки прерываний, организации загрузки и взаимодействия с оборудованием. Таким образом, PVH, как и режим PV, обеспечивает высокую производительность, благодаря исключению накладных расходов на симуляцию аппаратных устройств, но использует вместо PV MMU свойственные HVM механизмы аппаратной виртуализации для обеспечения более строгой изоляции виртуальных окружений.
    • При работе на системах с архитектурой ARM добавлена поддержка обеспечения защиты от модификации и выполнения блоков text и других данных в модулях ядра, помеченных только на чтение.
  • Аппаратные архитектуры
    • Добавлена поддержка семейства многопоточных многоядерных 32-разрядных процессоров interAptiv, построенных на базе архитектуры MIPS.
    • Для архитектуры m68k обеспечена поддержка системного вызова kexec().
    • В гипервизоре Xen прекращена поддержка архитектуры ia64.
    • Для архитектуры AMD64 добавлена поддержка меток перехода (jump labels) и системы распределения памяти CMA (Contiguous Memory Allocator), которая оптимизирована на выделение больших непрерывных областей памяти с использованием техники перемещения страниц памяти.
    • Поддержка платформ Intel Clovertrail (Atom Z2760), получившей распространение на планшетных ПК под управлением Windows, и Intel Merrifield MID (Atom Z3480), ориентированной на смартфоны.
    • В коде поддержки архитектуры xtensa добавлена поддержка многопроцессорных систем.
  • Оборудование
    • Поддержка переключения видеорежимов в пространстве пользователя (UMS) в DRM-драйвере Intel i915 объявлена устаревшей и будет удалена из работающих на уровне ядра компонентов драйвера через год. Доведена до стабильного состояния поддержка графической подсистемы процессоров на базе микроархитектуры Broadwell, которая придёт на смену Haswell.
    • В DRM-модуле драйвера Nouveau добавлена поддержка GPU NVIDIA серии GK110 ( GeForce GTX 780, GTX Titan) и GK208 (GeForce 630/640).
    • В DRM-модуле драйвера Radeon добавлена поддержка динамического управления питанием (DPM) для новых чипов AMD, в драйвере RadeonSI добавлена поддержка UVD-декодеров GPU.
    • В драйвере vmwgfx, позволяющем использовать 2D/3D-акселерацию в гостевых Linux-системах, работающих под управлением продуктов виртуализации VMware, обеспечена поддержка нового виртуального GPU (SVGA2 Hardware Revision 11).
    • Добавлена поддержка беспроводных адаптеров на базе чипов RealTek RTL8821AE и Marvell 8897, Ethernet-адаптеров на базе чипов Realtek RTL8153 и Intel XL710 X710 (Virtual Function Ethernet), виртуальных InfiniBand-интерфейсов Cisco (Virtual Interface InfiniBand).
    • В Video4Linux добавлена поддержка контроллеров web-камер SoC TI OMAP4, FM-приёмников из Broadcom BCM2048, Silicon Labs Si4713 FM и Thanko Raremono, DVB-S/S2 демодуляторов Montage M88DS3103, тюнеров Montage M88TS2022 и сенсоров камеры Samsung S5K5BAF.
    • Поддержка одночиповых платформ Marvell Berlin, Energy Micro EFM32, MOXA ART, Freescale i.MX50, Hisilicon Hi36xx/Hi37xx, Snapdragon 800 MSM8974, Freescale TWR-P102x PowerPC и Motorola/Emerson MVME5100.
    • Поддержка SDHCI-контроллеров Arasan.
    • Поддержка криптографических сопроцессоров AMD (CCP) и Freescale MXS DCP.


  1. Главная ссылка к новости (https://lkml.org/lkml/2014/3/3...)
  2. OpenNews: Релиз ядра Linux 3.13. Обзор новшеств
  3. OpenNews: Релиз ядра Linux 3.12. Планы по созданию ветки 4.0
  4. OpenNews: Релиз ядра Linux 3.11. Обзор новшеств
  5. OpenNews: Релиз ядра Linux 3.10. Обзор новшеств
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/39390-linux
Ключевые слова: linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (111) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, SergMarkov (ok), 08:53, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    zram это, конечно, хорошо
     
     
  • 2.15, Аноним (15), 10:06, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а как это, область памяти в памяти?
    и зачем?
     
     
  • 3.50, _KUL (ok), 12:44, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря. Резонный вопрос - если это из-за большой ОЗУ, то тогда зачем вообще делать своп в озу???
     
     
  • 4.57, ананим (?), 13:40, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вот этот для вас достаточно маленький?

    $ cat /proc/cpuinfo
    Processor       : ARMv7 Processor rev 0 (v7l)
    processor       : 0
    BogoMIPS        : 38.40

    processor       : 1
    BogoMIPS        : 38.40

    processor       : 2
    BogoMIPS        : 38.40

    processor       : 3
    BogoMIPS        : 38.40

    Features        : 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    : 0

    Hardware        : Qualcomm MSM 8974 (Flattened Device Tree)
    Revision        : 0000
    Serial          : 0000000000000000

     
  • 4.67, ram_scan (?), 14:25, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Узким местом давно стала не числомолотилка а шина и память что на ней болтается. Поэтому при кажущейся абсурдности такого изврата профит таки получается. Распаковать блок памяти выходит быстрее чем прогнать его по шине непакованным.
     
     
  • 5.73, pavlinux (ok), 16:08, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Мозг у тя узкое место.

    Посчитай на досуге, сколько тактов проца нужно, чтоб переколбасить
    в течении минуты, поток, со скоростью 6 Гб/сек. (прим. скорость шины).

    Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.

    Собственно, благодаря таким адцким скоростям, стало выгоднее делать блейд-сервера
    и кластеры, а не 1024 процессорные материнки.  

     
     
  • 6.80, noname 002 (?), 17:17, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще какой...
     
     
  • 7.85, www2 (??), 18:46, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ощущаете, но не понимаете, откуда он взялся. Ваше объяснение негодное. Шина тут не при чём, тут при чём скорость чтения-записи и позиционирования головок на жёстких дисках. С SSD такой проблемы нет - там уже всё упирается в скорость SATA. Придумают более быстрый интерфейс - профит от сжатого свопа в оперативке будет ещё меньше.
     
     
  • 8.89, Например (?), 19:21, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    есть SSD с интерфейсом PCIe ... текст свёрнут, показать
     
  • 7.109, pavlinux (ok), 01:17, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще
    > какой...

    Иди в венду ощущай. Млять, откуда вас столько выросло. Ощущают профит они... уссаца.

     
     
  • 8.111, Автобус (?), 07:12, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вот когда ты будешь делать обсчитывать фотограмметрию для интеграции со срочным ... текст свёрнут, показать
     
     
  • 9.147, pavlinux (ok), 03:23, 02/04/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это чё за высер тут нарисовался - будешь делать обсчитывать Ах да, срочные ... текст свёрнут, показать
     
     
  • 10.156, Алекс (??), 14:04, 08/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вам же четко написали- фотограмметрия, т е обработка изображений Это комплекс ... текст свёрнут, показать
     
  • 6.122, Аноним (-), 12:02, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.

    Ты уверен что на его девайсе с ARMv7 они есть? :)

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

    А диски как были слоупочными, так и остались. Поэтому своп на них - отвратителен по скорости работы. Свопиться на SSD - протрется в момент. Ну вот и пришли к компромиссному варианту - свопиться в оперативку :).

     
  • 6.140, Аноним (-), 15:53, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подробнее?
    Интересно знать, каким местом ацкие скорости PCIe и HT имеют отношение к построению кластеров.
     
     
  • 7.148, pavlinux (ok), 03:26, 02/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересно знать, каким местом

    трехкАнальным

     
  • 4.93, Аноним (-), 19:55, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря.

    Весьма зависит от того как это соотновится с I/O. Если I/O медленный, почему бы нет? :)

     
  • 2.16, Аноним (-), 10:06, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    1). Берём легко сжимаемые данные.
    2). Помещаем их в ZRAM, забив всё доступное место. Например 8 Гб при физически доступных 2 Гб.
    3). Внезапно удаляем 8 Гб легко сжимаемых данных и забиваем тяжело сжимаемыми данными, например H264-видео.
    4). ????
    5). Kernel Panic.

    Ну серьёзно, зачем умещать 700 Мб в 500 Мб, если внезапно может заполниться память? Зачем вообще хранить SWAP в памяти?! И это уже традиция в Linux. То фирменную технологию Google примут в ядро, которая позволяет на гигабайтной флешке создать сто стогигабайтных файлов, потому что "У нас на GMail лишь 1% использует все свои 100 Гб почты, так нафига месту простаивать?". То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.

     
     
  • 3.30, Zenitur (ok), 11:30, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Помнишь шутку про китайцев, которые попробовали по 1 пароль? Если каждый китаец зарегистрируется в GMail и заполнит на 100% своё место, GMail "упадёт"!
     
  • 3.37, AlexAT (ok), 11:40, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Затем, что диск - узкое место большинства систем. Ваш кэп.
     
     
  • 4.56, anonymous (??), 13:21, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Затем, что диск - узкое место большинства систем. Ваш кэп.

    Но зачем? Если памяти и так хватает, то нафиг подкачку. Прям веднузятничество какой-то. Только венда умудряется использовать своп при на 80% свободной памяти.

     
     
  • 5.60, rshadow (ok), 14:01, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Если памяти хватает, то и zram и swap остаются пустыми. Снова, ваш кэп.
     
  • 5.123, Аноним (-), 12:05, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Но зачем? Если памяти и так хватает, то нафиг подкачку.

    Довольно странно использовать zRAM, если памяти хватает. А вот когда ее МАЛО, при современной мощности числокрушилок сжатие может быть шустрее чем запись на тормозной носитель. Особенно на всяких мелких девайсах типа мобилок и т.п..

     
  • 3.62, Константин (??), 14:14, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Панику легко исключить резервированием достаточного дискового пространства для помещения несжатых данных. А все остальное - для скорости, как уже было сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста. В ЦОДах подавай эффективность, хоть винду ставь...
     
     
  • 4.141, Аноним (-), 15:56, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
    > В ЦОДах подавай эффективность, хоть винду ставь...

    Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте ЦОДов...

     
     
  • 5.144, Константин (??), 16:30, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
    >> В ЦОДах подавай эффективность, хоть винду ставь...
    > Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте
    > ЦОДов...

    Надежность (оно же "чтоб работало") - необходимое условие. Но не достаточное. Хотя конечно оно одно из первых обсуждается. ИМХО конечно.

     
  • 3.87, www2 (??), 19:06, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    И при чём тут сжимаемость данных Все 8 гигабайт этого видео не потребуются одно... большой текст свёрнут, показать
     
     
  • 4.142, Аноним (-), 16:00, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
    > Не мифической, а очень даже реальной. СУБД может сотни раз в секунду
    > перезаписывать одни и те же данные. Сделать сотни записей на диск
    > или одну - есть разница?

    Если СУБД сто раз за секунду перезаписала данные, они должны быть сто раз за секунду перезаписаны на диске. Логика BEGIN/COMMIT такое диктует для RDBMS, вроде как. Вернулись из COMMIT — данные ГАРАНТИРОВАННО записаны на диск.
    Если RDBMS заставляют сто раз в секунду перезаписывать одно и то же, кэшированием записи на диск это не решить, и не нужно.

     
  • 3.95, Андрей (??), 20:59, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не правы. Сжатие подкачки - это именно оно и есть. До того, как данные попадут в своп, они будут сжаты, что уменьшает количество дисковых оперций. Если памяти всё же не будет хватать - эти сжатые двнные будут вытеснены в своп. Не совсем понятно, зачем забивать память тяжкло сжимаемыми данными.
     
  • 3.121, Anonym2 (?), 10:51, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > То отложенную запись внедрят, чтобы добиться мифической
    > скорости записи на диск, тогда как физически записи не было.

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

     
  • 2.17, Аноним (-), 10:06, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    zram - это очень хорошо. Я его даже бэкпортировал на свое ядро 2.6.24.7 для IP приставки(blob'ы мешают перейти на что-то свежее)
     
     
  • 3.41, Seyko (?), 11:52, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
    встроенных устройств с их погибающим от частой записи flash-ПЗУ
     
     
  • 4.51, AlexAT (ok), 12:46, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
    > встроенных устройств с их погибающим от частой записи flash-ПЗУ

    Сейчас делаю вариант патча для ядра el6, если всё пройдёт нормально - выложу на тест.
    В ядре el6 zram из staging, к слову, уже имеется, однако он слишком старый.

    К сожалению, просто модулем - не получится, zram требует наличия аллокатора zsmalloc в mm-подсистеме ядра, в ядре el6 его нет. Поэтому только полная пересборка.

     
  • 4.75, Аноним (-), 16:11, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Портировать не сложно. Также модифицировать: так как в системе имелись статические буфера для видео/аудио декодеров и т.п., которые не использовались в некоторых случаях(загрузка обновлений в RAM и запись их во flash после загрузки), то был написан дополнительный allocator для модуля zram, который помещал несжимаемые данные в эти буфера.
     
  • 4.90, AlexAT (ok), 19:30, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
    > встроенных устройств с их погибающим от частой записи flash-ПЗУ

    Вариант для CentOS 6 тут:
    http://alex-at.ru/linux/zram-c6

    Для ядра OpenVZ адаптировать составить труда не должно - патч тот же, только .spec и конфиг чуток подправить.

     
  • 2.23, WherWolf (?), 11:05, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Интересно, можно ли будет хранить в сжатом виде не раздел подкачки, а, например, /var/log?
     
     
  • 3.25, ананим (?), 11:18, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы хотите логи в ram держать?
    Плохая идея.
    К тому же для логов итак логротэйт есть. С сжатием архивов и тд.
     
     
  • 4.48, Аноним (-), 12:39, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы хотите логи в ram держать?
    > Плохая идея.
    > К тому же для логов итак логротэйт есть. С сжатием архивов и
    > тд.

    Некоторые виды устройств, хранят логи в RAM памяти. Обычно на таких устройствах RAM в 4 раза больше чем Flash

     
     
  • 5.58, ананим (?), 13:51, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И что это должно доказывать?
    Что syslog должен теперь (как и эти устройства) в озу всё держать?

    Зыж
    эти устройства рассчитывают что их логи кто-то забирает.
    а если не забирает, то значит и не нужны, что в общем случае тут и не рассматривается (не ведите их тогда вообще).

     
  • 3.35, Lain_13 (ok), 11:36, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты боишься испортить логами новый SSD диск, то совершенно зря. Тебе придётся писать логи на полной скорости винта несколько лет к ряду, чтоб его испортить. А переносить логи в память просто так это действительно плохая идея.
     
     
  • 4.124, Аноним (-), 12:12, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > на полной скорости винта несколько лет к ряду, чтоб его испортить.

    Ага, ЩАЗ. Типичный NAND выдерживает 1-2 тысячи записей. За год можно переписать содержимое винта явно более 1000 раз. Другое дело что мало у кого такой конский объем логов.

     
     
  • 5.138, Lain_13_too_lazy_to_login (?), 13:44, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас все типичные SSD делают на TLC и MLC, а это 5 и 10 тысяч циклов. Нетипичные делают на SLC и это 100 000 и дорого. Ок, согласен, что про полную скорость я загнул, но логи в таких конских объёмах действительно редко пишутся и SSD на 120 Гб прослужит достаточно долго. В конце-концов тебе понадобится записать туда петабайт данных, чтоб высадить все ячейки. На современных винтах обычно указывают время до первого отказа при нормальной нагрузке и это обычно 1 200 000 часов для 120 Гб MLC (более 100 лет). Т.е. это если ты не пытаешься использовать винт на файловом сервере, например, с постоянной записью.
     

     ....большая нить свёрнута, показать (41)

  • 1.4, Аноним (-), 09:03, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Пугаясь размеру ядра от релиза к релизу, хочу спросить - сколько они занимают места?
     
     
  • 2.12, VldK (ok), 09:55, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В 4мб флеша моего роутера влезает помимо ядра 3.10 еще и вебморда с бизибоксом.
     
  • 2.28, Аноним (-), 11:25, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не пугайся. В винде драйвера отдельно от ядра, а здесь вместе. Поэтому сбивает с толку. Все драйвера лежат отдельно от ядра - в виде модулей (если не монолит).
     
  • 2.113, Андрей (??), 08:31, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    -rw-r--r-- 1 root root 6533680 апр  1 07:07 kernel-3.14.0-gentoo
    lz4
    ну да, на дискету уже давно не влазят...
     

  • 1.6, anonymous (??), 09:35, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это ядро просто обязано быть запущенным на Raspberry Pi.
     
     
  • 2.40, mihalych (ok), 11:49, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Запость фичреквест на pidora.ca
     
  • 2.79, Пиу (ok), 17:12, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    а они (или кто-нибудь) дрова в меинстрим спортировали? Грег говорил, что это удивительно, что rpi-шное ведро вообще работает
     

  • 1.10, Аноним (-), 09:47, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А еще геометрические шейдеры для radeon 2400-4970
    или нет?
     
     
  • 2.139, Аноним (-), 14:13, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ядро тут не виноватое
     

  • 1.13, Fracta1L (ok), 10:00, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Для файловой системы Btrfs расширен объём информации, предоставляемой через sysfs, в том числе теперь можно получить данные о доступных возможностях и использовании дискового пространства

    Отлично. А то с аудитом у Btrfs плоховато.

     
     
  • 2.20, Sasha (??), 10:54, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    c btrfs вообще всё плоховато
     
     
  • 3.22, ананим (?), 10:59, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А.. да-да.
    Не буду вам мешать общаться на "профессиональную" тему.

    Зыж
    Ха! Павлины говоришь?

     
  • 3.132, Аноним (-), 12:36, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > c btrfs вообще всё плоховато

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

     
  • 2.21, ананим (?), 10:55, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Аудит вешается на vfs.
    А то что вы подумали, называется отладка, профайлинг,.. всё что угодно, но точно не аудит.
    (Кстати то, про что вы подумали включается при конфигурации ядра/модуля ядра)
     

  • 1.27, Аноним (-), 11:24, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Объясните, зачем нужен zram? Всё исключительно из-за сжатия и теоретической возможности уместить больше данных в рам?
     
     
  • 2.32, ананим (?), 11:30, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да. Посмотрите кто именно этим заинтересован.
    В телефонах/планшетах иметь свап на ссд не всем нравится. Это уменьшает ресурс девайса (особенно когда в него хотят запихнуть железки из разряда "по-дешевле")
     
     
  • 3.152, Аноним (-), 13:15, 02/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?
     
     
  • 4.153, AlexAT (ok), 13:21, 02/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?

    Сжатие, сэр. Это несколько шустрее, чем посвопаться на диск. Тратя память на своп в ZRAM, в итоге получаем свободную память за счёт сжатия того, что "высвопили".

     
  • 2.36, Рыбак_из_Припяти (ok), 11:38, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для устройств с flash памятью, у которой маленькое число циклов записи.
     
  • 2.125, Аноним (-), 12:16, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > теоретической возможности уместить больше данных в рам?

    Поскольку большинство содержимого RAM отлично жмется, а упаковка/распаковка RAM быстрее чем запись на тормозной диск - можно в ряде ситуаций поиметь профит.

     

  • 1.38, Аноним (-), 11:44, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В DRM-модуле драйвера Nouveau добавлена поддержка GPU NVIDIA серии GK110 ( GeForce GTX 780, GTX Titan) и GK208 (GeForce 630/640).

    Надо же, и года не прошло. Попробовать, чтoле?

     
     
  • 2.77, pavlinux (ok), 16:20, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Попробовать, чтoле?

    Чо, целый год на Titan копил?!


     
     
  • 3.88, Аноним (-), 19:10, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не, целый год страдал на проприетарном драйвере. Плакал по ночам в подушку. Донатил мозелеедам во искупление греха сего.
     

  • 1.39, Аноним (-), 11:47, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что будет с hibernate, если своп в раме? Я надеюсь, его не повключают везде по дефолту?
     
     
  • 2.46, Andrew Kolchoogin (ok), 12:23, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В привычном смысле Hibernate в мобильных устройствах отсутствует, связь с ОпСоС'ом хотелось бы поддерживать постоянно. :)
     
     
  • 3.52, Аноним (-), 12:52, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистов.
     
     
  • 4.68, llolik (ok), 14:29, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистов

    как и забывать, что не везде используют ванильное ядро, среди "кулхацкеров".

     
  • 4.115, Андрей (??), 08:36, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с
    > "мабилой", видимо, уже традиция среди линуховых погромистов.

    Нормально всё - в сжатом виде и пишется. При загрузке разжимается...

     
  • 2.54, Imprtat (?), 13:01, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Данные "лежат" в zram до появления необходимости записать из на диск.
    Использовал zram в паре с убитым диском, очень выручал.
     

  • 1.42, iZEN (ok), 12:02, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Предлагаю SWAP делать просто файлом в tmpfs_со_сжатием. Ж)
     
     
  • 2.69, Аноним (69), 14:35, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    с разморозкой!!

    # egrep "(ZSWAP|ZRAM)" /usr/src/.config
    CONFIG_ZSWAP=y
    CONFIG_ZRAM=y
    # CONFIG_ZRAM_DEBUG is not set

     

  • 1.44, ua9oas (ok), 12:13, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В состав каких дистрибутивов оно войдет? Каков будет срок его жизни? Насколько больше устройств в нем поддерживается по сравнению с другими ветками ядра?
     
     
  • 2.70, Аноним (-), 14:42, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    для убунты уже есть пакеты на kernel.ubuntu.com
     
  • 2.116, Андрей (??), 08:38, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  В состав каких дистрибутивов оно войдет? Каков будет срок его жизни?
    > Насколько больше устройств в нем поддерживается по сравнению с другими ветками
    > ядра?

    не знаю как в других дистрах, но в gentoo-patches уже полгода точно присутствует...

     
     
  • 3.126, Аноним (-), 12:19, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > полгода точно присутствует...

    Мюнхаузен, залогинься! Ядро 3.14 пилят менее 2 месяцев, IIRC.

     

  • 1.59, svsd_val (ok), 13:54, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если озу кончалось???
    OOM уж больно долго думает (около 5-10минут) перед тем как убить тот или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не помогло =(
     
     
  • 2.63, Аноним (-), 14:14, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Сделать swap меньше. Пока kswapd будет способен перекидывать страницы между ram и swap, у OOM не будет причин сработать.
     
     
  • 3.84, svsd_val (ok), 17:46, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У меня просто 16gb, я свап вообще не врубал, думал что он влияет на OOM killer....
     
     
  • 4.127, Аноним (-), 12:20, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня просто 16gb, я свап вообще не врубал,

    Ну и правильно. Нафиг вам своп с 16Гб?

     
     
  • 5.134, svsd_val (ok), 13:23, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Дык, вот поэтому его и не врубал, но каким то макаром, смог повесить систему на минут 5-10 при срабатывании OOM Killer'а Oo
     
     
  • 6.151, Linux 3.14 (?), 12:37, 02/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Дык, вот поэтому его и не врубал, но каким то макаром, смог
    > повесить систему на минут 5-10 при срабатывании OOM Killer'а Oo

    Просто ядро при недостатке памяти сначала сбрасывает все дисковые кэши и потом при каждом обращении к файловой системе ходит непосредственно на диск, а не в кэш. И это выглядит как подвисание, несмотря на то, что свопа в системе нет вовсе.

     
  • 2.117, Андрей (??), 08:39, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
    > озу кончалось???
    > OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
    > или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
    > помогло =(

    А в BSD наоборот - очень быстро :D

     
     
  • 3.136, svsd_val (ok), 13:27, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
    >> озу кончалось???
    >> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
    >> или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
    >> помогло =(
    > А в BSD наоборот - очень быстро :D

    Угу при "ручном" аллокэйте - он срабатывает мгновенно, но скорее всего из-за видюхи (она юзает часть озу) он и повесился на это время. (Видюха встроенная Intel GMA)

     
  • 2.130, Аноним (-), 12:31, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
    > или иной процесс,

    Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и выюзавшая программа пристрелились весьма резво.

     
     
  • 3.137, svsd_val (ok), 13:30, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
    >> или иной процесс,
    > Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как
    > раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и
    > выюзавшая программа пристрелились весьма резво.

    Похоже это из-за того что у меня в то время была запущена игрушка и она начала аллокейтить озу в видюхе, в то время когда кончалась озу и вот результат .. (видюха встроенная intel gma)

     
  • 2.146, Аноним (-), 20:37, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит "сильные подвисания"? Зависание оно или есть, или его нет. Просто как немного беременная.
     

  • 1.65, анонимммм (?), 14:20, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    как всегда обделили драйвера для n7260 wifi (обещали полную поддержку в 14 ядре)
     
  • 1.74, alp (?), 16:10, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это ж блин Пи ядро :)
     
     
  • 2.118, Андрей (??), 08:41, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это ж блин Пи ядро :)

    точно же! щас в грубе версию поправлю :)

     
  • 2.119, Андрей (??), 08:42, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это ж блин Пи ядро :)

    Надо так - π !

     

  • 1.83, pavlinux (ok), 17:32, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    tcp_autocorking  - предохранитель от разгона интернета! :)  
     
  • 1.91, AlexAT (ok), 19:30, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Бэкпорт для CentOS 6 тут:
    http://alex-at.ru/linux/zram-c6
     
     
  • 2.94, AlexAT (ok), 20:45, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Бэкпорт для CentOS 6 тут:
    > http://alex-at.ru/linux/zram-c6

    Бэкпорт ZRAM, конечно же.

     
  • 2.107, pavlinux (ok), 01:07, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Бэкпорт для CentOS 6 тут:

    А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
    а еще раньше валялось ненужное под именем compcache на гуглекоде.

    Какие-то вы тормоза. :D

     
     
  • 3.112, AlexAT (ok), 08:14, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,

    На самом деле для специфичных применений вполне нужное, но из staging бэкпортировать было лениво.


     
     
  • 4.133, Andrey Mitrofanov (?), 13:16, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
    > вполне нужное, но из staging бэкпортировать было лениво.

    /lib/modules/2.6.32-279.el6.x86_64/kernel/drivers/staging/zram/zram.ko

    ?? П-поясни? Чем твой "бэкпорт" лучше /staging?

     
     
  • 5.135, AlexAT (ok), 13:27, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ?? П-поясни? Чем твой "бэкпорт" лучше /staging?

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

    Если сравнивать со staging из штатного ядра RHEL - то там совсем тихий ужас. Во-первых, используется старый, как говно мамонта, вариант. Во-вторых, там используется другой, "навесной" аллокатор для сжатых страниц.

     
  • 3.129, Аноним (-), 12:28, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нyжное.,

    Пока ты каркал, это замайнлайнили. Прокаркал ты свой тезис.

     
     
  • 4.155, pavlinux (ok), 14:07, 04/04/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лошара ты малолетняя. Пока ты ф школе азбуку учил, я эту куету вдоль и поперёк изучил.
    Хрень это не нужная. Для ИБД можешь заюзать ZSWAP
     
  • 3.157, Michael Shigorin (ok), 15:40, 09/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно с ядра 2.6.33 валяется никому не нужное.,

    Использовано в http://altlinux.org/LTSP (с 2.6.22), для тонких клиентов бывает крайне полезно -- led@ по этому поводу вкручивал статистику, набранную отправляли разработчикам.

     
  • 2.159, AlexAT (ok), 18:47, 13/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Апдейт бэкпорта ZRAM в ядро CentOS 6: http://alex-at.ru/linux/zram-c6

    1. Версия 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

     

  • 1.102, Аноним (-), 23:33, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > изменений внесено сотрудниками компании Intel, 7.3%

    AMD пофиг на Linux, интересно как там дела с 3DNow!

     
     
  • 2.103, Аноним (-), 23:33, 31/03/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    + FMA; 3DNowExt
     
  • 2.106, Led (ok), 01:01, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> изменений внесено сотрудниками компании Intel, 7.3%
    > AMD пофиг на Linux, интересно как там дела с 3DNow!

    Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.

     
     
  • 3.120, Андрей (??), 08:43, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> изменений внесено сотрудниками компании Intel, 7.3%
    >> AMD пофиг на Linux, интересно как там дела с 3DNow!
    > Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.

    <NOTROLL>Я не совсем ронял, почему они отказались от 3dnow% ?</NOTROLL>

     
     
  • 4.154, Stax (ok), 00:25, 03/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Инструкции не пользовались особой популярностью Фактически большинство из них я... большой текст свёрнут, показать
     
  • 2.128, Аноним (-), 12:26, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > AMD пофиг на Linux,

    В чем это выражается? Процы и чипсеты поддерживаются, GPU пилят ударными темпами. А ничего иного амд вроде и не выпускает так по крупному...

     

  • 1.131, Аноням (?), 12:34, 01/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А ещё Линус Торвальдс заявил об изменении нумерации сборок: следующая - 3,141, потом - 3,1415 и далее. Релиз "Тäydellisyys" выйдет после полного завершения разработки.
     
     
  • 2.143, Аноним (-), 16:14, 01/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Лавры Кнута спать спокойно не дают?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру