The OpenNET Project / Index page

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

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

20.01.2014 07:11

После двух с половиной месяцев разработки Линус Торвальдс выпустил ядро Linux 3.13. Среди наиболее заметных улучшений: интеграция пакетного фильтра Nftables, включение по умолчанию режима TCP Fast Open, увеличение производительности Squashfs, поддержка протокола HSR для создания отказоустойчивых сетевых конфигураций, добавление нового высокопроизводительного слоя блочных устройств, поддержка автоматического переключения между GPU в драйвере Radeon, фреймворк для ограничения энергопотребления устройств, классификатор трафика на основе BPF, реализация средств для проведения защищённых финансовых транзакций по NFC, поддержка архитектуры Intel MIC.

В новую версию принято 12 тысяч исправлений от 1339 разработчиков, размер патча - 32 Мб (изменения затронули 9849 файлов, добавлено 441972 строки кода, удалено 237897 строк). Около 44% всех представленных в 3.13 изменений связаны с драйверами устройств, примерно 21% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 4% - файловыми системами и 5% c внутренними подсистемами ядра. 11.9% изменений внесено сотрудниками компании Intel, 9.7% - Linaro, 9% - Red Hat, 5% - Samsung, 3.5% - IBM, 2.7% - SUSE, 1.7% - Google, 1.5% - NVIDIA, 1.1% - Oracle, 1.0% - Huawei, 0.9% - ARM.

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

  • Сетевая подсистема
    • Интеграция пакетного фильтра Nftables, развиваемого для замены iptables, ip6table, arptables и ebtables. Добавленный в ядро 3.13 код предусматривает сосуществование старой и новой подсистем, так как Nftables ещё требует доработки и тестирования. Nftables основывается на идеях, близких к реализации BPF (Berkeley Packet Filters) - правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро через API Netlink, после чего для принятия решения по дальнейшим действиям с пакетом выполняются с использованием конечного автомата (pseudo-state machine). Выполнение правил с использованием конечного автомата вместо применения логики сопоставления позволяет сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователя.

      В Nftables работа с различными видами протоколов унифицирована в едином наборе псевдокода, что позволяет избавиться от необходимости поддержания в ядре отдельных расширений фильтрации для IPv4, IPv6, ARP и сетевых мостов. Все операции по определению условий и связанных с ними действий выполняются в пространстве пользователя (формируется байткод). В ядре при выполнении сформированного в пространстве пользователя байткода производится только базовый набор операций, таких как чтение данных из пакета, сравнение данных и т.п. Для реализации поддержки фильтрации нового протокола все изменения могут быть внесены в пользовательском пространстве без обновления кода ядра. В качестве базовых блоков по-прежнему используются компоненты инфраструктуры Netfilter, в том числе существующие хуки, система отслеживания состояния соединений, компоненты организации очередей и подсистема ведения лога.

      Для формирования правил фильтрации в nftables подготовлена утилита nft, которая проверяет корректность правил и транслирует их в байткод. Правила могут добавляться не только инкрементально, но и загружаться целиком из файла на диске. Синтаксис правил не похож на iptables и отличается использованием иерархических блочных структур вместо линейной схемы. Язык классификации правил основан на реальной грамматике, при обработке которой используется сгенерированный в bison парсер. Для обеспечения обратной совместимости с линейными правилами предоставляется специальная прослойка, позволяющая использовать iptables/ip6tables поверх инфраструктуры Nftables.

    • Интегрирован легковесный классификатор трафика, выступающий в качестве гибко настраиваемой альтернативы ematch-классификатору. Особенностью нового классификатора является использование виртуальной машины BPF (Berkley Packet Filter) для выполнения программы классификации трафика, загружаемой в ядро в форме байткода, который в том числе может компилироваться в машинные инструкции при помощи BPF JIT-компилятора. Для загрузки bpf-правил используется штатная утилита tc, например "tc filter add dev em1 parent 1: bpf run bytecode-file /etc/tc/ssh.bpf flowid 1:1". Для создания bpf-правил может использоваться компилятор bpfc или tcpdump: "tcpdump -iem1 -ddd port 22 | tr '\\n' ',' > /etc/tc/ssh.bpf".
    • Включена по умолчанию поддержка режима быстрого открытия TCP-соединений (TFO - TCP Fast Open), который позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения и даёт возможность отправки данных на начальном этапе установки соединения.
    • В ipset добавлена поддержка сетевых пространств имён (network namespaces), предоставлена возможность использования комментариев в записях, добавлены модули "hash:net,net" и "hash:net,port,net" для указания двух подсетей в одной записи.
    • Поддержка протокола HSR (High-availability Seamless Redundancy) для создания высокодоступных резервных Ethernet-каналов, обеспечивающих сохранение работоспособности сети при выходе из строя одного из каналов без задержки на восстановление. Для обеспечения отказоустойчивости в HSR используется кольцевая топология, в которой все узлы соединены с использованием двух дублирующих друг-друга каналов, каждый из которых используется в параллельном режиме. Для контроля целостности в обоих направлениях кольца отправляются специальные HSR-фреймы. HSR-драйвер создаёт специальный виртуальный сетевой интерфейс, с которым можно работать как с обычным сетевым интерфейсом.
    • Для сетевых сокетов представлена поддержка опции SO_MAX_PACING_RATE, позволяющей приложению выставить значение максимальной интенсивности обработки пакетов на транспортном уровне. Лимит задаётся в байтах в секунду. Опция эффективно работает только с планировщиком пакетов Fair Queue.
    • В стек IPv4 для сокетов добавлена поддержка режима IP_PMTUDISC_INTERFACE, позволяющего игнорировать механизм Path MTU discovery, т.е. не принимать и устанавливать новую информацию Path MTU, а всегда использовать параметры MTU сетевого интерфейса для отправляемых пакетов. Данная опция может оказаться полезной для блокирования манипулирующих PMTU атак на DNS-серверы.
    • В интерфейсы виртуальных туннелей IPsec (vti) добавлена поддержка IPv6.
    • Добавлена возможность использования непривилегированными пользователями некоторых вызовов sysctl (например, /proc/sys/net/ipv4/ip_local_ports_range или /proc/sys/net/ipv4/icmp_echo_ignore_all) для изолированных сетевых пространств имён (network namespaces).
  • Дисковая подсистема, ввод/вывод и файловые системы
    • Для эффективного использования возможностей современных SSD-накопителей в ядро включен новый блочный слой (Linux block layer), рассчитанный на организацию многопоточного доступа к данным на многоядерных системах. Архитектура нового блочного слоя основана на двухуровневой модели очередей: на первом уровне функционируют очереди для передачи запросов ввода/вывода, привязанные к каждому CPU. Из данных очередей запросы направляются в очереди второго уровня, которые координируют обращение к оборудованию. В зависимости от конфигурации системы, числа CPU и накопителей соотношение между очередями первого и второго уровня может составлять от 1 к 1 до N к M.

      Тестирование показало высокую эффективность нового блочного слоя, который смог обеспечить производительность в многие миллионы операций ввода/вывода в секунду, т.е. показал способность справиться с пропускной способностью современных устройств NVM-Express и PCI-E на многоядерных системах, сохранив при этом типовой интерфейс и привычные возможности слоя для работы с блочными устройствами. Старый блочный слой обеспечивал производительность порядка 800 тысяч операций в секунду, не масштабируясь от числа CPU, чего было достаточно для накопителей на жёстких магнитных дисках, но уже не хватает для SSD-накопителей, производительность которых перешагнула рубеж к 1 млн операций в секунду.

    • Существенно ускорена работа специализированной файловой системы SquashFS, обычно используемой в качестве ФС для установочных образов, Live-систем и прошивок. SquashFS поддерживает доступ только для чтения, но обеспечивает при этом компактное представление метаданных и позволяет хранить данные в сжатом виде. В частности, реализована возможность непосредственной распаковки в кэш страниц (page cache), что позволяет избежать лишних операций копирования и уйти от эксклюзивной блокировки буфера. Также добавлена поддержка многопоточной распаковки сжатых данных и параллельного ввода/вывода. В зависимости от характера нагрузки и конфигурации системы, внесённые оптимизации позволяют ускорить работу SquashFS в разы, например, в одном из тестов скорость возросла с 13 MB/s до 67 MB/s. Изменения особенно заметны на многоядерных системах и при выполнении параллельного чтения данных.
    • В системе Bcache, которая позволяет организовать кэширование доступа к медленным жестким дискам на быстрых SSD-накопителях, добавлена поддержка инкрементального сборщика мусора, позволяющего свести к минимуму задержки при выполнении операций чистки кэша от устаревших элементов и повысить эффективность расходования места в кэше.
    • В модуле dm-cache, предназначенном для ускорения доступа к жестким дискам через применение кэширования на SSD-накопителях, добавлен режим сквозного проброса (passthrough), применяемого, когда неизвестно, насколько содержимое кэша согласовано с содержимым базового устройства. В данном режиме все операции чтения выполняются с базового накопителя, минуя кэш, а операции записи перенаправляются на базовое устройство с использованием кэширования. Например, режим passthrough может быть установлен загрузочным скриптом после экстренной перезагрузки, что позволит сохранить возможность кэширования записи до момента выполнения утилиты для восстановления целостности кэша. Кроме того в dm-cache добавлена поддержка операции урезания кэша и очистки блоков из кэша.
    • В файловой системе Btrfs добавлена поддержка опций монтирования commit (задаёт интервал периодических коммитов, по умолчанию 30) и rescan_uuid_tree (инициирует процесс проверки и перестроения дерева UUID). Добавлен флаг FIEMAP_EXTENT_SHARED, позволяющий организовать совместное использование экстентов разными inode.
    • Для файловых систем SMB2/SMB3 добавлена поддержка клонирования файлов при копировании на стороне сервера (по аналогии с "cp --reflink"), а также возможность определения настроек сжатия для отдельных файлов (через "chattr +c filename"). Добавлена опция CONFIG_CIFS_STATS2 для сбора информации о сетевых адаптерах, что удобно использовать для отладочных целей.
    • Для F2FS представлена настройка CONFIG_F2FS_CHECK_FS, позволяющая отключить механизм проверки согласованности ФС на лету, влияющий на производительность.
  • Виртуализация и безопасность
    • Поддержка API Secure Element для организации выполнения защищённых операций с использованием протокола NFC. С практической стороны при реализации надлежащей поддержки на пользовательском уровне теперь предоставлены все необходимые средства для совершения платежей и финансовых транзакций с использованием NFC. Новый API пока поддерживается только драйвером pn544;
    • Внесена серия улучшений в генератор псевдослучайных чисел: увеличена производительность, повышено качество энтропии, улучшена работа на платформах, отличных от х86. Генератор 32-разрядых случайных чисел prandom32*() переведён с алгоритма taus88 на taus113, который обеспечивает периодичность 2^113. Изменён метод задействования аппаратных генераторов случайных числе (например, RDRAND в новых CPU Intel), вместо смешивания итоговых значений буфера при помощи оператора XOR, данные из RDRAND примешиваются в пул энтропии на стадии его формирования.
    • Добавлено устройство KVM-VFIO, позволяющее огранизовать взаимодействие гипервизора KVM c построенными с использованием механизма VFIO драйверами устройств, работающих в пространстве пользователя. В KVM обеспечена поддержка работы на системах с процессором ARM Cortex-A7;
    • Улучшения в SELinux: Обеспечена возможность установки контекста безопасности для rootfs (ramfs) в привязке к inode, что например может быть использовано для привязки метки к файлу, когда ФС не предоставляет обработчик xattr. Добавлен признак always_check_network, при включении которого всегда производится проверка пакетов и пиров, независимо от активности SECMARK и включения меток для пиров, т.е. даже если SECMARK-правила не определены для netfilter и отсутствует конфигурация на основе Netlabel или меток в IPSEC. Проведены оптимизации, позволившие снизить накладные расходы при использовании SELinux (по тесту AIM7 выигрыш для систем с 1100-2000 пользователями составляет 2.6%).
  • Память и системные сервисы
    • Добавлен Power Capping Framework, предоставляющий унифицированный интерфейс для управления настройками ограничения энергопотребления устройств из пространства пользователя. В частности, фреймворк позволяет через sysfs-интерфейс /sys/devices/virtual/powercap задать ограничения энергопотребления для устройств, поддерживающих механизм Intel RAPL (Running Average Power Limit), реализованный в процессорах Intel начиная с Sandy Bridge и ожидаемый в будущих моделях различных типов устройств;
    • Для систем на базе архитектуры NUMA задействован набор политик, позволяющих планировщику задач более эффективно организовывать выполнение процессов на подобных системах. Реализованные политики нацелены на размещение процессов и связанной с ними памяти в рамках одного NUMA-узла, а также на обработку таких ситуаций как совместное использование страниц памяти несколькими процессами. Подобная локализация процессов и связанной с ними памяти важна, так как на NUMA-системах каждый CPU снабжён отдельным контроллером памяти и несмотря на то, что каждый CPU может обращаться к любым областям памяти, обращение к областям, адресуемым локальным контроллером памяти данного CPU, осуществляется заметно быстрее, чем к областям, привязанным к контроллерам памяти других CPU. Для управления включением тех или иных политик работы планировщика представлены соответствующие sysctl-переменные.
    • Проведена работа по увеличению масштабируемости при организации доступа к таблицам страниц памяти в условиях, когда выполняются операции со страницами памяти большого размера (hugepage). В частности, при использовании hugepages вместо монолитного блокирования частей таблиц страниц памяти теперь используются более гранулированные блокировки, позволяющие увеличить масштабируемость при применении многопоточности.
    • Увеличена производительность и эффективность распределения памяти в механизме slab. Изменения коснулись методов управления свободными объектами в кэшах kmem_caches, в которых хранятся объекты, размером 128 байт и меньше. В итоге, число попаданий в кэш увеличилось на 5%, что привело к увеличению производительности slab на 3.1%.
    • Увеличена масштабируемость epoll на системах с большим числом CPU за счёт переработки организации блокировок. Тестирование на системе с 16 CPU показало увеличение производительности с 35k jOPS до 125k jOPS в тесте SPECjbb.
    • Реализация NFC digital layer. Большинство NFC-чипсетов реализуют данный слой на уровне прошивки, но встречаются и такие, в которых поддерживается только аналоговый слой NFC. Добавлена поддержка технологий NFC-A (106 kbits/s), NFC-F (212 kbits/s и 424 kbits/s), NFC-DEP initiator/target и цифрового стека протоколов (Digital Protocol stack).
    • В Bluetooth-стеке реализована возможность создания виртуальных AMP-контроллеров, поддержка установки режима DUT (Device Under Test), добавлена команда mgmt_set_bredr для включения и отключения функций BR/EDR, добавлена команда для установки статического адреса для контроллеров, поддерживающих режимы BR/EDR и LE, добавлена поддержка нового HCI-сокета для управления определённым HCI-устройством из пользовательского приложения.
    • Добавлен новый фреймворк Generic PHY Framework для разработки драйверов для подключаемых устройств, в том числе внешних сетевых адаптеров, SATA и USB устройств.
    • Добавлена утилита tmon, которую можно использовать для мониторинга работы подсистемы температурного контроля.
  • Аппаратные архитектуры
    • Поддержка архитектуры Intel MIC (Many Integrated Core), используемой в сопроцессорах, имеющих форм-фактор карт PCIe и способных выполнять 64-разрядные экземпляры Linux. Интегрированный в ядро драйвер нацелен на управление состоянием экземпляров ОС и обеспечение взаимодействия между хост-системой и системой на карте сопроцессора. В настоящее время обеспечена поддержка сопроцессоров Intel MIC X100, которые, в частности, используются в самом высокопроизводительном кластере Tianhe-2, использующем архитектуру MIC для достижения производительности в 33.86 PetaFLOPS.
    • Максимальное число CPU для архитектуры x86 увеличено с 4096 до 8192;
    • Поддержка архитектуры ARM big.LITTLE и гетерогенных многопроцессорных ARM-систем. Поддержка субархитектуры big-endian ARM "BE8".
    • Для архитектуры ARM64 добавлена поддержка систем big-endian, горячего подключения CPU и 42-разрядного виртуального адресного пространства при использовании страниц памяти размером 64 Кб;
    • Для архитектуры PowerPC добавлена поддержка систем little-endian;
    • Для архитектуры SPARC64 реализована полная поддержка tickless-режима, не зависящего от сигналов таймера. Размер больших страниц (huge pages) памяти для архитектуры SPARC64 увеличен с 4MB до 8MB.
  • Оборудование
    • Серия значительных улучшений в DRM-модуле Radeon:
      • Поддержка GPU семейства "Hawaii" (R9 290X). Обеспечена поддержка UVD-декодера, управление питанием (DPM) и сменой видеорежимов;
      • Стабилизирована и по умолчанию активирована поддержка динамического управления питанием и частотами (DPM) для большинства современных встроенных и внешних видеокарт Radeon. С практической стороны DPM позволит обеспечить оптимальное энергопотребление в условиях автономной работы и добиться максимальной производительности для конфигураций, работающих на заниженной частоте;
      • По умолчанию включена поддержка вывода звука через HDMI, в том числе с использованием кодеков DTS-HD и Dolby TrueHD, а также с поддержкой конфигурации объёмного звука 7.1;
      • Поддержка динамического включения и выключения дискретного GPU в основанных на технологии AMD PowerXpress ноутбуках с двумя GPU;
      • Внесены изменения, позволившие существенно увеличить производительность HD7000 и более новых GPU, поддерживаемых в Mesa Gallium3D-драйвером RadeonSI;
    • В DRM-драйвере Intel i915 появилась поддержка графической подсистемы процессоров на базе микроархитектуры Broadwell, которая придёт на смену Haswell;
    • Добавлен DRM-модуль для видеоподсистемы Marvell Armada 510 SoC;
    • В DRM-модуль Tegra добавлена поддержка 3D для Tegra20, Tegra30 и Tegra114. Для Tegra114 также добавлена поддержка HDMI.
    • Поддержка систем NVIDIA Tegra T124, Renesas r7272100, r8a7791
    • Поддержка звуковых интерфейсов на базе чипа TC Applied Technologies DICE;
    • Поддержка беспроводных адаптеров на базе чипов Qualcomm Atheros WCN3660/3680
    • Поддержка сетевых интерфейсов Sony Port-100 Series USB NFC, MOXA ART MDIO.


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


Обсуждение (120) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Fracta1L (ok), 07:36, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Фороникс утверждает, что в 3.13 наблюдаются ощутимые регрессии в дисковой подсистеме (отчасти из-за недоработанного ещё нового блочного слоя). Пожалуй, пропущу этот релиз и подожду 3.14
     
     
  • 2.14, Аноним (-), 09:44, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Phoronix тестировал rc, может исправили.
     
  • 2.20, Аноним (-), 10:16, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что за регрессии? Тесты повалились?
     
  • 2.31, Аноним (-), 11:26, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Фореникс как всегда прав.
     
     
  • 3.91, Аноним (-), 16:43, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Фореникс как всегда прав.

    Слово "как" в вашем заявлении - лишнее.

     
     
  • 4.114, р323234 (?), 20:52, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Оно не меняет смысла, так что без разницы
     
     
  • 5.139, Аноним (-), 02:21, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Зато отлично передает контекст.
     
  • 3.133, Mr_Gentoo (ok), 23:50, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Фореникс как всегда прав.

    Фороникс как всегда лев.

     
     
  • 4.142, Аноним (-), 03:50, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Генту как всегда позади планеты всей.
    Особенно, по скорости развития.
     
     
  • 5.155, Аноним (-), 15:44, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Фороникс, залогинься.
     
  • 2.38, Sergey722 (ok), 12:22, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Фороникс утверждает:
    The Linux 3.13 Kernel Is A Must-Have For AMD RadeonSI Users
    Там прирост производительности в пять раз - не самый впечатляющий результат.
    Вот такой он противоречивый - Фороникс.
     
     
  • 3.39, Fracta1L (ok), 12:25, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Серёжа, нельзя же так люто упарываться, это совершенно разные подсистемы. Где ты тут противоречие увидел?
     
     
  • 4.40, Sergey722 (ok), 12:41, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ладно, уговорили, не буду :)
    Все равно, улучшения в графике радуют!
     
     
  • 5.43, ананим (?), 12:50, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +9 +/
    >поддержка автоматического переключения между GPU в драйвере Radeon

    Дык у обладателей амд праздник. Одним этим предложением утерли нос нвидиа.

     
     
  • 6.53, Fracta1L (ok), 13:54, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да, наконец-то начали доставать до носа нвидиа. Встав на цыпочки -))
     
  • 6.109, Аноним (-), 20:35, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дык у обладателей амд праздник. Одним этим предложением утерли нос нвидиа.

    Для них 3.13 - это эпохальный кернел. Если у вас не слишком древняя видеокарта, DPM активированный по дефолту порадует вас холодным GPU в режиме ничегонеделания и отличной производительностью при нагрузке.

    //к сожалению я нашел в нем баг, ну вот почему баги лезут сразу после релизов, а не до?!

     
     
  • 7.146, Аноним (-), 10:59, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >к сожалению я нашел в нем баг, ну вот почему баги лезут сразу после релизов, а не до?!

    А почему ты ищешь баги после релиза, а не до?

     
     
  • 8.153, arisu (ok), 15:35, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    а с каких пор 171 пользоваться 187 стало равно 171 ищешь баги 187 ... текст свёрнут, показать
     
  • 3.84, pkunk (ok), 16:33, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    From: Marek Olšák <marek.olsak@amd.com>

    Only the render backends of the first shader engine were enabled. The others
    were erroneously disabled. Enabling the other render backends improves
    performance a lot.

    Unigine Sanctuary on Bonaire:
      Before: 15 fps
      After:  90 fps

    Judging from the fan noise, the GPU was also underclocked when the other
    render backends were disabled, resulting in horrible performance. The fan is
    a lot noisy under load now.

     
     
  • 4.110, Аноним (-), 20:36, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Unigine Sanctuary on Bonaire:
    >   Before: 15 fps
    >   After:  90 fps

    Учитесь как фиксы надо выкатывать. А юзеры Bonaire должны поставить Marek'у памятник при жизни вообще.

     
  • 4.148, Аноним (-), 13:04, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Этот же коммит включем в ядра >=3.12.7, если что.
     
  • 2.60, бро (?), 14:50, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если хочешь, можно подождать и более совершенную - 3.141
     
     
  • 3.66, Fracta1L (ok), 15:21, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Если хочешь, можно подождать и более совершенную - 3.141

    Нет, стоит подождать абсолютно совершенную - 3.14159265359... и так далее -))

     
     
  • 4.99, Аноним (-), 19:08, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Нет, стоит подождать абсолютно совершенную - 3.14159265359... и так далее -))

    $ latex --version
    pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)

     
     
  • 5.143, Аноним (-), 04:42, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Когда Кнут умрет, согласно его завещанию, версии tex и metafont примут значения равные π  и e соответственно, а все баги станут считаться особенностями реализации.
     
  • 2.93, Sylvia (ok), 16:53, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    настоящие джедаи не должны поддаваться лжи провороникса :D

    обновила на 2 серверах, с производительностью диска все ОК, правда там и конфиг минимальный у ядра

     
     
  • 3.111, Аноним (-), 20:37, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > настоящие джедаи не должны поддаваться лжи провороникса :D

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

     
     
  • 4.127, arisu (ok), 22:12, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну поскольку мадам не выкатила никаких тестов лучше - мы будем предпочитать
    > фороникса.

    а мы — не будем. индекс доверия у обоих источников примерно одинаковый.

     
     
  • 5.128, Аноним (-), 22:38, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > а мы

    "Мы, Николай Вторый..."

     
     
  • 6.140, arisu (ok), 02:42, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> а мы
    > «Мы, Николай Вторый…»

    это к #111

     
  • 4.135, Аноним (-), 00:09, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Почему нельзя унижать девушек на опеннете?
     
     
  • 5.141, arisu (ok), 02:44, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Почему нельзя унижать девушек на опеннете?

    можно. но за дело. но сильви очень старательно избегает «дела».

     
  • 5.156, Аноним (-), 15:45, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Почему нельзя унижать девушек на опеннете?

    Персонально тебе - вообще ничего здесь нельзя. Страдай.

     
  • 2.160, Sylvia (ok), 10:46, 24/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    не знаю можно ли назвать это регрессией, но дисковая активность явно выросла на обоих обновленных до 3.13 серверах без видимых внешних причин

    iops
    http://storage5.static.itmages.ru/i/14/0124/h_1390545883_4934154_7200361440.p

    load avg
    http://storage7.static.itmages.ru/i/14/0124/h_1390545892_4010914_48ef1a0f2d.p

     
     
  • 3.164, Аноним (-), 14:49, 29/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ССЗБ :(
     
  • 3.165, Аноним (-), 14:50, 29/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    На серверах .0 ядра используют только камикадзе или новички. Либо у вас сервер локалхоста, тогда понятно.


     

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

  • 1.4, Andrey Mitrofanov (?), 07:56, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    http://www.opennet.me/openforum/vsluhforumID3/92256.html#303
     
  • 1.12, Аноним (-), 09:37, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что лучше, dm-cache или Bcache ?
     
     
  • 2.23, Гость (?), 10:23, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А что лучше, dm-cache или Bcache ?

    Для вас лучше dm-cache.

     

  • 1.13, Аноним (13), 09:38, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а когда в роутерах перестанут наконец использовать ржавое прержавое ядро 2.6?
     
     
  • 2.16, Гость (?), 10:05, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Когда пресвежие ядра станут такими же оттестированными как 2.6 и производителям кровь из носа потребуется функционал из новых ядер.
     
     
  • 3.25, Andrey Mitrofanov (?), 10:55, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Когда пресвежие ядра станут такими же оттестированными как 2.6 и производителям кровь
    > из носа потребуется функционал из новых ядер.

    Или когда новые ядра с "новым функционалом" похудеют до размеров флэшей тех роутеров.

     
  • 3.45, Аноним (-), 13:01, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ой, вот не надо тут сказок про заботу о потребителе. Причина тривиальна - жаба давит за размер флеш-памяти и денег на капитальный апгрейд прошивок.
     
  • 2.33, Онаним (?), 11:51, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а когда в роутерах перестанут наконец использовать ржавое прержавое ядро 2.6?

    Уж как год назад (25th April 2013):

    ATTITUDE ADJUSTMENT 12.09 / Highlights since Backfire 10.03.1:

    - Switched to Kernel 3.3
    - snip -

     
     
  • 3.54, dalco (ok), 13:57, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А в openwrt'шном trunk'е так и 3.10 уже.

    P.S. Правда, не каждый снапшот оттуда удачен ;) Но мне _чаще всего_ везло :)

     
  • 3.102, Miha (??), 19:38, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> а когда в роутерах перестанут наконец использовать ржавое прержавое ядро 2.6?
    > Уж как год назад (25th April 2013):
    > ATTITUDE ADJUSTMENT 12.09 / Highlights since Backfire 10.03.1:
    > - Switched to Kernel 3.3
    > - snip -

    Ну да и теперь не меньше 32Мбайт памяти надо.

     
  • 2.120, Аноним (-), 21:41, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > а когда в роутерах перестанут наконец использовать ржавое прержавое ядро 2.6?

    Используйте openwrt, там ядро не ржавое.

     
     
  • 3.157, Аноним (-), 15:45, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> а когда в роутерах перестанут наконец использовать ржавое прержавое ядро 2.6?
    > Используйте openwrt, там ядро не ржавое.

    Не ржавое - значит нестабильное же.

     

  • 1.15, Moomintroll (ok), 09:57, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Переводчика на мыло!

    > правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро через API Netlink
    > Все операции по определению условий и связанных с ними действий выполняются в пространстве пользователя, в ядре производится только базовый набор операций, таких как чтение данных из пакета, сравнение данных и т.п.

    Так где же будет производиться фильтрация, в ядре или в пространстве пользователя?

    Вообще что-то невнятное... Если фильтрация в пространстве пользователя, то чем она отличается от NFQUEUE и какого-нибудь демона с шахматами и поэтессами?

     
     
  • 2.17, Аноним (-), 10:10, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Так где же будет производиться фильтрация, в ядре или в пространстве пользователя?

    Вчитайтесь в отквоченный вами текст и ещё раз прочитайте первый абзац в новости, там  ясно сказано, что делается в  пространстве пользователя. Какие проверки будет делать загруженный байткод определяется в пространстве пользователя. В ядро уже подготовленный в пространстве пользователя байткод грузится, который выполняется в специальной виртуальной машине.

     
  • 2.19, Гость (?), 10:16, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это от того что вы невнимательно читаете. Правила задаются в юзерспейсе, компилируется в байткод и передается ядру, а в ядре только сравниваются байты из пакета с байтами в правилах. => Фильтрация производится в ядре.
     
     
  • 3.26, Andrey Mitrofanov (?), 10:58, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >компилируется в байткод и передается ядру, а в ядре только сравниваются байты
    > из пакета с байтами в правилах.

    FIX: Байт-код не "сравнивается", он исполняется.

     
  • 2.28, gapsf2 (ok), 11:11, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В userspace происходит компиляция естественно с проверкой синтаксиса и ошибок ... большой текст свёрнут, показать
     

  • 1.18, Аноним (-), 10:13, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждём появление джавы  уровня ядра. С пользовательского уровня через апи формируешь код и он выполняется на уровне ядра.
     
     
  • 2.22, Аноним (-), 10:20, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Для ядра NetBSD уже Lua запилили http://www.opennet.me/opennews/art.shtml?num=38203
    Для Linux тоже начинали что-то похожее делать, но проект загнулся так ничего и не родив.
     
     
  • 3.27, цирроз (ok), 11:09, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ничего хорошего из таких проектов и не получится
     
     
  • 4.71, Аноним (-), 15:40, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ничего хорошего из таких проектов и не получится

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

     
     
  • 5.100, жабабыдлокодер (ok), 19:09, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А были проекты оси на жабе. Только вот дальше проектов дело не пошло, к сожалению... Хотя для Солариса ДЕ на ней, родимой, сделали. И работало вполне неплохо.
     
     
  • 6.122, Аноним (-), 21:43, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И работало вполне неплохо.

    ...если Cray прикупить...

     
     
  • 7.129, Аноним (-), 22:40, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> И работало вполне неплохо.
    > ...если Cray прикупить...

    Человек, который любит смотреть, как резво бегают улитки, не замечает тормозов JavaOS.

     
     
  • 8.131, жабабыдлокодер (ok), 22:50, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там было два варианта, второй со второгномом Запускал в виртуалбоксе, разницы п... текст свёрнут, показать
     
     
  • 9.158, Аноним (-), 15:47, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А первый от него чем-то отличался, кроме названия ... текст свёрнут, показать
     
  • 6.145, Аноним (-), 04:46, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А были проекты оси на жабе. Только вот дальше проектов дело не
    > пошло, к сожалению... Хотя для Солариса ДЕ на ней, родимой, сделали.
    > И работало вполне неплохо.

    В солярисе Java Desktop - это такой переименованный гном. От джавы там одно название, чтобы тырпрайз клевал.

     
  • 5.144, Аноним (-), 04:45, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > sysvinit и openrc возвышаются над системДой.

    Вроде, такое положение не "возвышаются" зовется, а совсем наоборот.


     
  • 2.48, Аноним (-), 13:07, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Есть такая штука... байт-код... в Java...
     

  • 1.29, AlexAT (ok), 11:12, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Как сетевика - наиболее радуют NPF и TC-BPF.

    Интересно, насколько легко удастся бэкпортировать сии вкусности в ядро RH7.

     
     
  • 2.41, daks (ok), 12:41, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Есть ненулевая вероятность, что шапка портирует сама, учитывая, что это не изменение, а добавление и семёрочка всё ещё в бэте.
     

  • 1.35, ua9oas (ok), 12:02, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В состав каких дистрибутивов оно войдет? (и когда?) И прежде чем оно так куда войдет,- а как много до этого его там где-либо "прикрутят"? (а в каких случаях стоит это делать?)
    Какое количество новаго оборудования оно стало поддерживать (и сколько его теперь осталось того, которое в линуксе все еще не поддерживается?)
     
     
  • 2.36, Аноним (-), 12:10, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В Арче, Генте, наверное уже сегодня.
     
  • 2.76, koblin (ok), 15:50, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в грядущей убунте (14.04) оно вроде уже есть
     
  • 2.90, Аноним (-), 16:41, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В Федоре стопудово будет. Может даже в 19-й.
     
     
  • 3.92, Аноним (-), 16:52, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    20-я уже на дворе ))
     
     
  • 4.95, Аноним (-), 17:37, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Я имел в виду, что даже в старую 19-ю запихнут новое ведро ;)
     
     
  • 5.98, Аноним (-), 19:07, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Что, прямо как в ubuntu и arch?
     

  • 1.51, Аноним (-), 13:23, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По ссылке про Nftables первый же комментарий:

    You must be joking. This got pulled in?
    “Building a basic ruleset”?! Wow. The direction of Linux development never ceases to amaze me.

    Собственно, такие же ощущения были.

     
     
  • 2.56, gapsf2 (ok), 14:25, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    По умолчанию встроенных таблиц filter, mangle, nat и цепочек INPUT, OUTPUT... большой текст свёрнут, показать
     
  • 2.58, vitalif (ok), 14:36, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ой, да нормально. Как будто iptables интуитивно понятен. Если постоянно не юзать - всё равно забываешь каждый раз, что там да как называется...
     
     
  • 3.61, Perain (?), 14:51, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –6 +/
    По сравнению с ipfw, iptables полный выродок!
     
     
  • 4.70, Аноним (-), 15:36, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Это называется "синдром утенка".
     
  • 4.83, pavlinux (ok), 16:32, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > По сравнению с ipfw, iptables полный выродок!

    По сравнению с bpf, ipfw ущербное говно!

     
     
  • 5.85, Perain (?), 16:35, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    в этом согласен http://citrin.ru/freebsd:ng_ipfw_ng_bpf
     
     
  • 6.94, pavlinux (ok), 17:00, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > в этом согласен http://citrin.ru/freebsd:ng_ipfw_ng_bpf

    BPF нужен тем, кто пишет iptables, свои фаерволы, системы управления трафиком, и пр.
    Сисадмину, и тем более хомякам, это геморрой на 5 лет вперёд по изучению и разбору
    на биты всего стека IP.

     
  • 4.103, Miha (??), 19:45, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > По сравнению с ipfw, iptables полный выродок!

    Вы шутник. Для двух карт - может быть, а вот когда у вас сложная топология, то айпитаблес - лучшее решение. В ipfw per-interface acl только в прошлом году стало возможным. Так что не надо.

     
     
  • 5.105, Аноним (-), 20:07, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    айпитаблес не может быть лучшим решением, потому что не работает под FreeBSD.
     
     
  • 6.112, pavlinux (ok), 20:46, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > айпитаблес не может быть лучшим решением, потому что не работает под FreeBSD.

    Ещё один повод выкинуть BSD

     
  • 6.124, Аноним (-), 21:45, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > потому что не работает под FreeBSD.

    А что под ней вообще работает? Полторы бестолковых файловых системы, недопиленная виртуализация и пакетный манагер для галочки? Крутая система для крутых пасанов.


     
  • 6.126, Аноним (-), 22:04, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > потому что не работает под FreeBSD.

    это не беда, ~BSD не нужно.

     
  • 4.159, user455 (?), 19:54, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не забуду freebsd 6, когда я сидел и день за днем разбирался с ipfw в купе с его правилами и divert к natd. сколько разбирался - не помню, но было это долго и нудно.
    потом, спустя год я откырл pf и разобрался с ним за 3и часа. а потом еще пару дней игрался.
    спустя еще год я открыл iptables (nf) и разобрался с ним за час. он мне показался самы клевым , удобным и логичным фаером из всех, что я видел.

     

  • 1.59, pavlinux (ok), 14:43, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Макс, для рандома еще вот это патчик

    random: mix in architectural randomness earlier in extract_buf()
    Previously if CPU chip had a built-in random number generator (i.e.,
    RDRAND on newer x86 chips), we mixed it in at the very end of
    extract_buf() using an XOR operation.

    We now mix it in right after the calculate a hash across the entire
    pool.  This has the advantage that any contribution of entropy from
    the CPU's HWRNG will get mixed back into the pool.  In addition, it
    means that if the HWRNG has any defects (either accidentally or
    maliciously introduced), this will be mitigated via the non-linear
    transform of the SHA-1 hash function before we hand out generated
    output.

    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers

     
     
  • 2.106, pavlinux (ok), 20:08, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Макс, отменяй новость, там всё опять поломали, XOR больше не нужен! :D

    https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=ab




    /*
    - * If we have a architectural hardware random number
    - * generator, mix that in, too.
    + * If we have an architectural hardware random number
    + * generator, use it for SHA's initial vector
    */
    + sha_init(hash.w);
    for (i = 0; i < LONGS(20); i++) {
    unsigned long v;
    if (!arch_get_random_long(&v))
    break;
    - hash.l[i] ^= v;
    + hash.l[i] = v;
    }



    А я и говорил: XOR - палево:  http://www.opennet.me/openforum/vsluhforumID3/93572.html#61

     
     
  • 3.116, Sage (??), 21:18, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Опять с указателями балуешься, Павлуша?
     
     
  • 4.136, pavlinux (ok), 00:11, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Опять с указателями балуешься, Павлуша?

    :-P

     

  • 1.63, Аноним (-), 14:58, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    9849 файлов?
    Я думал в ядре всего один файл.
     
     
  • 2.125, Аноним (-), 21:46, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Я думал в ядре всего один файл.

    А еще Земля - не плоская. И солнце вокруг нее не вращается. Ща ты у нас много нового узнаешь...

     

  • 1.72, anonymous (??), 15:41, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Увеличена масштабируемость epoll на системах с большим числом CPU за счёт переработки организации блокировок. Тестирование на системе с 16 CPU показало увеличение производительности с 35k jOPS до 125k jOPS в тесте SPECjbb.

    Линукс-торт!

     
     
  • 2.149, vitalif (ok), 14:15, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Показало увеличение производительности до 125к жопс...
     

  • 1.74, pavlinux (ok), 15:45, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/



    + while (true) {
    + s64 count;
    +
    + spin_lock_irq(q->queue_lock);
    + count = percpu_counter_sum(&q->mq_usage_counter);
    + spin_unlock_irq(q->queue_lock);
    +
    + if (count == 0)
    + break;
    + blk_mq_run_queues(q, false);
    + msleep(10);
    + }



    Вот не хорошо как-то - sleep() без причин и объяснений.

     
     
  • 2.96, AlexAT (ok), 18:00, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А иначе будет spinlock contention между CPU. 1/100000 секунды слипа для избежания lock contention, если не требуется realtime-реакция - нормально.
     
     
  • 3.101, pavlinux (ok), 19:22, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пред новым годом в USB срач был, сколько делать таймаут после ресета: 10 ms или 20  

    Я не против, мож это и так, но блин можно было сделать:

    #define NO_SPNLK_CONT_TMOUT (HZ/100) // иль тупа 10, но только объяснить, почему 10, а не 15
    ...
    msleep(NO_SPNLK_CONT_TMOUT)
    ---

    А сейчас это похоже на детские хаки в хелловордах - sleep(1),
    "просто слип, хрен знает зачем, но чую подождать надо, не знаю сколько,
    но навсякий случай пишу 1 сек."


     
     
  • 4.104, asavah (ok), 19:51, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    дык напиши в LKML, может примут.
    я твои патчи уже на себе опробовал (для блоба ынвидии и для vmware vmnet-only на "новых" ядрах) и они очень даже нормально работают.
     
  • 4.118, Аноним (-), 21:21, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    от HZ уже давно отвязались. Этот кейс и так понятен, выбирают эмпирически от балды на глаз.
     
     
  • 5.137, pavlinux (ok), 00:20, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > от HZ уже давно отвязались.

    Чтоб отвязаться от HZ на машине должен быть стабильный TSC,
    в ширпотребе это минимум материнки после 2012 года.
    Либо нормальный RTC, с не плавающей частотой.

     
     
  • 6.147, Аноним (-), 11:12, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы отвязаться от HZ нужно просто отвязаться от HZ. HZ это не таймер, а метод квантования планировщика задач.
     
     
  • 7.152, pavlinux (ok), 14:55, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чтобы отвязаться от HZ нужно просто отвязаться от HZ. HZ это не
    > таймер, а метод квантования планировщика задач.

    Кванты будем по рандому генерить?

     
  • 4.150, vitalif (ok), 14:17, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А сейчас это похоже на детские хаки в хелловордах - sleep(1),
    > "просто слип, хрен знает зачем, но чую подождать надо, не знаю сколько,
    > но навсякий случай пишу 1 сек."

    Так между прочим DM работает...)))

    drivers/block/md/dm-kcopyd.c:

    /*
    * Sleep this number of milliseconds.
    *
    * The value was decided experimentally.
    * Smaller values seem to cause an increased copy rate above the limit.
    * The reason for this is unknown but possibly due to jiffies rounding errors
    * or read/write cache inside the disk.
    */
    #define SLEEP_MSEC                      100

     
     
  • 5.151, pavlinux (ok), 14:55, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А сейчас это похоже на детские хаки в хелловордах - sleep(1),
    >> "просто слип, хрен знает зачем, но чую подождать надо, не знаю сколько,
    >> но навсякий случай пишу 1 сек."
    > Так между прочим DM работает...)))

    Ну видишь, эти хоть честно признались. :)

     
  • 5.154, arisu (ok), 15:36, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > работает

    ключевое слово.

     

  • 1.97, гошт (?), 18:35, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    HSR - это хорошо, а что с реализацией PRP (Parallel Redundancy Protocol), описанном в стандарте IEC 62439-3?
     
  • 1.107, Sylvia (ok), 20:20, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://storage6.static.itmages.ru/i/14/0120/h_1390234731_4659122_c3764acc19.p

    изменения в ГСЧ забавно смотрятся на графике мунина, больше энтропии :D

     
     
  • 2.113, pavlinux (ok), 20:51, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Прилепи вот этот патчик https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=ab

    ---
    И сейчас эти сисцтлины чему равны?

    kernel.random.read_wakeup_threshold
    kernel.random.write_wakeup_threshold

     
     
  • 3.115, Sylvia (ok), 21:13, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    kernel.random.read_wakeup_threshold = 64
    kernel.random.write_wakeup_threshold = 896

    патчить буду когда .1 выйдет, хотя наверное этот патч там уже и будет

     
     
  • 4.132, pavlinux (ok), 23:47, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Неа, в 3.14 пойдёт, хотя мож пофиксят вот это:




    -static int max_read_thresh = INPUT_POOL_WORDS * 32;
    +static int max_read_thresh = OUTPUT_POOL_WORDS * 32;



     
  • 3.130, Аноним (-), 22:49, 20/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Прилепи вот этот патчик https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=ab

    А что он дает?

     
     
  • 4.134, pavlinux (ok), 00:03, 21/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Прилепи вот этот патчик https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=ab
    > А что он дает?

    Мне - ничего, у меня RDRAND нигде нету, а у кого есть - вот тут уже рассказал:  
    http://www.opennet.me/openforum/vsluhforumID3/93616.html#106

    Ну и фикс

    -static int max_read_thresh = INPUT_POOL_WORDS * 32;
    +static int max_read_thresh = OUTPUT_POOL_WORDS * 32;

     

  • 1.108, lucentcode (ok), 20:33, 20/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хороший релиз. Особенно внедрение нового файрвола и новый блочный слой радует.
     
  • 1.138, Заоза (ok), 00:31, 21/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    а как же закон Мура?
     
  • 1.161, Аноним (-), 04:05, 29/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите, а есть ли какой-то способ начать пользоваться этой версией ядра? Есть ли какие-то очень быстрые дистрибутивы? Может быть какой-то RPM Based? А как вы вообще тестируете сами? Неужеле ставите из исходников и собираете?
     
     
  • 2.162, Andrey Mitrofanov (?), 09:44, 29/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ли какие-то очень быстрые дистрибутивы? Может быть какой-то RPM Based?

    Ну, говорят, там есть make rpm. Да-да, прямо там.

    > А как вы вообще тестируете сами? Неужеле ставите из исходников и собираете?

     
  • 2.163, arisu (ok), 14:16, 29/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > как вы вообще тестируете сами? Неужеле ставите из исходников и собираете?

    нет, я линуса припахал. ему всё равно делать нечего. он мне сам звонит периодически и просит: «ну потестируй ядро, а то я сам не умею. я вот тебе даже собрал, ты только потестируй!»

     

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



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

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