LINUX.ORG.RU

Linux 6.14

 , , ,

Linux 6.14

0

5

После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.14. Среди наиболее заметных изменений: драйвер ntsync c примитивами синхронизации Windows NT, настройка балансировки операций чтения в Btrfs RAID1, поддержка reflink в XFS в режиме realtime, возможность некэшируемого буферизированного ввода/вывода, dmem cgroup для ограничения памяти GPU, задействование io_uring в FUSE, делегирование атрибутов в NFS, поддержка атомарной записи в Device mapper, ускорение символических ссылок, управление возможностью выполнения скриптов, поддержка чипов Qualcomm Snapdragon 8 Elite, драйвер для NPU AMD.

В новую версию принято 12115 исправлений от 1984 разработчиков, размер патча – 39 МБ (изменения затронули 10170 файлов, добавлено 531586 строк кода, удалено 235999 строк). В прошлом выпуске было 14172 исправлений от 2086 разработчиков, размер патча – 46 МБ. Около 41% всех представленных в 6.14 изменений связаны с драйверами устройств, примерно 13% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 7% – с файловыми системами и 4% c внутренними подсистемами ядра.

Основные новшества:

  • Дисковая подсистема, ввод/вывод и файловые системы
    • В файловой системе Btrfs появилась поддержка новых методов балансировки операций чтения между накопителями, входящими в массив RAID1. Помимо ранее действующего распределения нагрузки на основе идентификаторов процессов (pid), в новой версии предложены три новых режима балансировки: «rotation» (равномерное распределение нагрузки по всем накопителям, режим включён по умолчанию); «latency» (распределение с учётом задержек, может быть полезным при сбоях или нестабильной работе накопителей); devid (ручное управление). Для изменения режима балансировки добавлен интерфейс /sys/fs/btrfs/<UUID>/read_policy. Среди других изменений в Btrfs – реализация ioctl FS_IOC_READ_VERITY_METADATA.
    • Добавлен режим некэшируемого буферизированного ввода/вывода, при котором данные удаляются из страничного кэша сразу после того, как завершены операции по их чтению или записи. Изменение может быть полезным при использовании очень быстрых устройств хранения, кэширование операций с которыми в оперативной памяти избыточно. Для таких устройств новый режим позволяет исключить излишнее расходование памяти страничным кэшем не прибегая к использованию усложнённого API прямого ввода/вывода (Direct I/O).
    • В fsnotify, механизм отслеживания изменений в ФС, добавлено новое событие FS_PRE_ACCESS, генерируемое на стадии перед обращением к содержимому файла. Событие обрабатывается в синхронном режиме, т. е. ядро отправляет событие и ожидает получения ответа. Если ответ получен – операция выполняется, а если произошёл сбой – системный вызов возвращает в пространство пользователя код ошибки. При помощи FS_PRE_ACCESS процессом в пространстве пользователя, например, может быть организовано заполнение файла по мере готовности данных в медленном хранилище.
    • В подсистему FUSE, позволяющую создавать реализации файловых систем в пространстве пользователя, добавлена поддержка обмена данными между ядром и обработчиком в пространстве пользователя с использованием механизма ввода/вывода io_uring. Изменение позволяет повысить производительность FUSE за счёт сокращения переключений контекста между ядром и пространством пользователя.
    • В файловую систему XFS добавлена возможность использования обратного маппинга (rmap, reverse-mapping) в режиме работы с предсказуемыми задержками («realtime device»). Обратный маппинг позволяет определить для хранения какого файла используется указанный блок на устройстве хранения. При помощи rmap в XFS для realtime-режима реализована поддержка операции reflink, позволяющей создавать копии файлов путём клонирования метаданных файла и создания ссылки на уже имеющиеся данные без их фактического копирования.
    • В VFS реализовано кэширование размера символических ссылок, позволившее на 1.5% ускорить выполнение операции readlink (в тесте с /initrd.img в ext4). Кэширование включено в ФС ext4 и tmpfs.
    • В реализацию NFSv4.2 добавлена поддержка делегирования атрибутов файлов, позволяющая управлять такими атрибутами файлов, как время изменения (mtime), на стороне NFS-клиента, без необходимости сброса изменений на сервер. В NFS также улучшена поддержка протокола «LOCALIO», позволяющего определить находятся ли клиент и сервер NFS на одном и том же хосте, для задействования соответствующих оптимизаций, таких как использование клиентом прямого ввода/вывода (Direct I/O).
    • Повышена производительность операций чтения в файловых системах NETFS, CIFS и AFS (Andrew File System).
    • В Squashfs включён режим прямой загрузки блоков в страничный кэш (SQUASHFS_FILE_DIRECT), позволяющий обойтись без отдельного кэша read_page. Изменение позволило сократить размер памяти, потребляемой при работе Squashfs.
    • В системном вызове statx() реализован флаг STATX_DIO_READ_ALIGN, для определения требуемого выравнивания для операций чтения из файла.
    • В файловой системе Bcachefs обновлён и стабилизирован формат дисковых структур. Любые дальнейшие изменения формата будут отнесены к категории необязательных и будут реализовываться в форме опциональных дополнений. Значительно повышена скорость проверки целостности ФС. Кроме того, в Bcachefs улучшена работа в режиме только для чтения; устранены проблемы, приводящие к обращению к памяти после её освобождения (use after free); решены проблемы c reflink-указателями в fsck; исправлена обработка перезапуска транзакции.
    • Возвращён модуль md-linear, предназначенный для объединения блочных устройств. Данный модуль ранее был объявлен устаревшим и удалён из ядра 6.8, но как оказалось он был востребован и поэтому теперь восстановлен.
    • Файловые системы F2FS и SQUASHFS переведены на использование фолиантов страниц памяти (page folios).
    • В драйвере null_blk реализован атрибут «rotational», выставляемый через configfs и позволяющий симулировать работу с устройством на базе вращающихся дисков для упрощения тестирования функций ядра.
    • В системе Device mapper и в модулях dm-mirror, dm-io, dm-table, dm-linear, dm-stripe и dm-raid1 реализована поддержка атомарной записи.
  • Память и системные сервисы
    • Завершена интеграция в ядро драйвера ntsync, реализующего символьное устройство /dev/ntsync и набор примитивов для синхронизации, применяемых в ядре Windows NT. Реализация подобных примитивов на уровне ядра позволяет существенно поднять производительность Windows-игр, запускаемых при помощи Wine. Прирост производительности достигается благодаря избавлению от накладных расходов, связанных с применением RPC в пространстве пользователя. Создание отдельного драйвера для ядра Linux объясняется проблематичностью корректной реализации API синхронизации NT поверх существующих примитивов в ядре.
    • Добавлен новый контроллер cgroup DMEM для раздельного учёта областей памяти устройств, таких как GPU. DMEM позволяет создавать отдельные cgroup для различных задач, работающих с GPU, чтобы они могли выполняться не влияя друг на друга. Новая возможность решает проблему с принудительным завершением операций с GPU при исчерпании доступной памяти, благодаря учёту отражённой памяти GPU и используемой драйверами памяти CPU в отдельных cgroup.
    • Внесены оптимизации по масштабированию операции сброса (flush) кэша TLB (Translation Lookaside Buffer), применяемого для ускорения преобразования виртуальных адресов в физические. Добавленные оптимизации сводятся к отложенному обновлению некоторых структур данных во время переключения контекста, что позволяет повысить производительность при прохождении некоторых тестов.
    • Повышена производительность механизма MGLRU (Multi-Generational LRU), применяемый для определения какие страницы памяти используются, а какие можно вытеснить в раздел подкачки.
    • Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру). Предоставлена возможность использования в коде ядра макроса «derive(CoercePointee)», позволяющего использовать умные указатели с trait-объектами. В состав ядра включены Rust-обвязки для PCI, платформ, Open Firmware, символьных устройств и некоторых функций ввода/вывода. Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, охарактеризовал текущее состояние, как «почти готовность к написанию реального драйвера на Rust».
    • В сборочных сценариях предложен новый код для генерации версий отладочных символов для загружаемых модулей, который теперь использует информацию из отладочных записей в формате DWARF, а не разбирает исходный код напрямую. Изменение позволяет применять версионирование отладочных символов для модулей, написанных на языке Rust. Старая реализация тоже оставлена в ядре, а выбор генератора производится на уровне сборочных опций.
    • Для архитектуры PowerPC реализована поддержка режима ленивого вытеснения задач (PREEMPT_LAZY, lazy preemption), который соответствует режиму полного вытеснения («full preemption») для realtime-задач (RR/FIFO/DEADLINE), но задерживает вытеснение обычных задач (SCHED_NORMAL) до границы тика.
    • В подсистему профилирования производительности perf добавлена поддержка счётчиков энергопотребления процессоров AMD. Добавлена возможность работы на системах, насчитывающих до 2048 ядер CPU.
    • Предоставлена возможность использования sysctl-параметра pid_max с пространствами имён идентификаторов процессов (ID namespace). Параметр pid_max предназначен для ограничения максимального значения идентификаторов процессов (PID) и теперь может использоваться для ограничения максимально возможного числа процессов, запущенных в указанном пространстве имён. Обработка параметра производится иерархически, т. е. ограничения во внешних пространствах имён распространяются на вложенные пространства имён.
    • При использовании для запуска процесса системного вызова execveat в файловой системе /proc теперь будет отображаться имя запущенного файла, а не номер файлового дескриптора.
    • В состав исходного кода ядра (в каталог samples) добавлена утилита mountinfo, демонстрирующая использование системных вызовов statmount() и listmount().
    • В подсистеме BPF предложены новые функции bpf_local_irq_save() и bpf_local_irq_restore() для временного отключения прерываний на локальном CPU. Функции могут применяться для реализации структур, обработка которых не приостанавливается прерываниями.
    • В системном вызове madvise() при использовании флагов MADV_DONTNEED и MADV_FREE обеспечено освобождение таблиц страниц памяти, связанных с освобождаемым диапазоном адресов, так как в некоторых ситуациях пустые страницы памяти могут занимать достаточно много памяти.
    • Для архитектуры OpenRISC реализована поддержка механизма перезапускаемых последовательностей (rseq, restartable sequences), предназначенного для быстрого атомарного выполнения операций, которые в случае прерывания другим потоком очищаются и предпринимается повторная попытка выполнения.
    • Проведена реорганизация кода с реализацией алгоритмов CRC32 и CRC-T10DIF, который больше не пересекается с подсистемой crypto и вызывается напрямую из библиотечного интерфейса. Изменение позволило упростить код и повысить его эффективность.
    • В систему асинхронного ввода/вывода io_uring добавлен интерфейс для передачи дополнительных метаданных о целостности при выполнении операций чтения и записи.
  • Виртуализация и безопасность
    • В системный вызов execveat добавлен флаг AT_EXECVE_CHECK, позволяющий выполнить проверку допустимости исполнения файла без его фактического запуска, но c учётом политик безопасности, прав доступа и активных LSM-модулей. Для использования в сочетании с AT_EXECVE_CHECK предложены securebit-флаги SECBIT_EXEC_RESTRICT_FILE и SECBIT_EXEC_DENY_INTERACTIVE, которые можно использовать для ограничения исполнения файлов со скриптами на интерпретируемых языках программирования. Флаг SECBIT_EXEC_RESTRICT_FILE предписывает компоновщикам и интерпретаторам использовать опцию AT_EXECVE_CHECK для проверки допустимости исполнения, а флаг SECBIT_EXEC_DENY_INTERACTIVE запрещает обрабатывать интерактивные команды. Основная идея изменения в возможности применения политик безопасности не только к традиционным исполняемым файлам, но и к текстовым файлам со скриптами, которые можно загрузить через запуск интерпретатора (т. е. запрет на исполнение может быть реализован не только при запуске «./script.sh» но и при выполнении в форме «sh script.sh»).
    • На системах x86 реализована поддержка защищённых счётчиков времени для гостевых систем, не позволяющих изменять системные часы гостевой системы из хост окружения. Возможность реализована на базе механизма AMD SEV (Secure Encrypted Virtualization), применяемого в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.
    • В систему мандатного контроля доступа SELinux добавлена поддержка xperm-правил, позволяющих привязывать политики SELinux к определённым вызовам ioctl() или сообщениям netlink.
    • Для заверения модулей ядра цифровой подписью вместо SHA1 по умолчанию задействован алгоритм SHA512.
    • В драйверах для гостевых систем VirtualBox включена поддержка архитектуры ARM64.
    • В гипервизоре KVM продолжена работа над задействованием механизма Intel TDX (Trusted Domain Extensions) для шифрования памяти гостевых систем.
    • В virtio_blk добавлена поддержка режима восстановления ошибок.
  • Сетевая подсистема
    • В реализации протокола RxRPC появилась возможность использования больших кадров UDP для повышения пропускной способности.
    • Для TCP добавлена поддержка алгоритма RACK-TLP для определения потери пакетов.
    • Добавлен новый параметр sysctl tcp_tw_reuse_delay, действующий в привязке к пространству имён (network namespace) и позволяющий определить задержку, вносимую перед тем как система сможет повторно использовать номер сетевого порта после закрытия TCP-сокета.
    • Добавлена возможность выбора провайдера точного времени (PTP) для формирования временных меток на уровнях PHY и MAC.
    • Для IPsec реализована поддержка механизма агрегирования и фрагментирования инкапсулированных IP-пакетов – IP-TFS/AGGFRAG (IP Traffic Flow Security/Aggregation and Fragmentation Mode for Encapsulating Security Payload).
    • В систему сетевых сокетов добавлена поддержка передачи информации о приоритете (SO_PRIORITY) в форме управляющих сообщений (cmsg - control messages). Для сетевых сокетов добавлена опция SO_RCVPRIORITY, включающая в функции recvmsg() передачу информацию о приоритете сокета.
  • Оборудование
    • Добавлен драйвер amdxdna для интегрированных в CPU AMD ускорителей NPU (Neural Processing Unit) на базе архитектуры XDNA, предназначенных для ускорения операций, связанных с машинным обучением. NPU на базе архитектуры XDNA поставляется в сериях 7040 и 8040 процессоров AMD Ryzen, ускорителях AMD Alveo V70 и SoC AMD Versal.
    • В драйвер i915 добавлены идентификаторы новых GPU, реализован обработчик сбоев инициализации HDMI, повышена надёжность сброса движков GPU на Haswell и более старых системах.
    • Продолжена работа над drm-драйвером (Direct Rendering Manager) Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake.
    • В драйвере Nouveau добавлена возможность передачи буферов с логами GSP-RM через debugfs.
    • В драйвере AMDGPU реализована поддержка механизма DRM panic, отображающего подобие «синего экрана смерти» при сбоях. Продолжена подготовка к поддержке будущей серии графических карт Radeon RX 9000 на базе архитектуры RDNA4. Обновлена поддержка DCN 3.5, GG 9.5, IH 4.4, PSP 13.x, SMU 13.x, VCN 5.x, JPEG 5.x, GC 12.x, DC FAMS, RAS и ISP.
    • В DRM-драйвер msm (GPU Qualcomm Adreno) добавлена поддержка платформы Qualcomm SM6150 (QCS615).
    • В DRM-драйвер panfrost добавлена поддержка SoC MediaTek MT8188 c GPU Mali-G57.
    • В DRM-драйвер vc4 добавлена поддержка SoC Broadcom BCM2712 (Raspberry Pi 5).
    • В vfio-драйвер nvgrace-gpu добавлена поддержка чипов NVIDIA Grace Blackwell 200.
    • В состав включён драйвер для контроллеров Intel THC (Touch Host Controller), применяемый для взаимодействия с сенсорными экранами и тачпадами на некоторых ноутбуках. Добавлена поддержка устройств Wacom с интерфейсом PCI. Добавлена поддержка игровых контроллеров QH Electronics.
    • Добавлена поддержка ARM-плат, SoC и устройств: Qualcomm Snapdragon 8 Elite (SM8750), Qualcomm Snapdragon AR2 (SAR2130P), Qualcomm IQ6/IQ8, Snapdragon 425 (MSM8917), Samsung Exynos 9810, Blaize BLZP1600, Microchip SAMA7D65, Renesas R-Car V4H ES3.0, Renesas RZ/G3E. Добавлена поддержка SoC SpacemiT K1 на базе архитектуры RISC-V.
    • В звуковой подсистеме ALSA для MIDI 2.0 расширены API rawmidi и sequencer. В API для выноса операций сжатия на сторону звуковой карты добавлена поддержка ASRC (Asynchronous Sample Rate Conversion).
    • Добавлена поддержка звуковых систем устройств Allwinner suinv F1C100s, Awinc AW88083, Realtek ALC5682I-VE, TAS2781, Focusrite Scarlett 4th Gen 16i16, 18i16 и 18i20. Добавлена поддержка беспроводных наушников SteelSeries Arctis 9.

>>> Подробности на OpenNET

★★★★★

Проверено: CrX ()

В новую версию принято 12115 исправлений от 1984 разработчиков, размер патча – 39 МБ (изменения затронули 10170 файлов, добавлено 531586 строк кода, удалено 235999 строк).

Кто-нибудь сравнивал производительность работы старых и новых ядер «Линукса» при одних и тех же настройках и при работе на той же самой электронной аппаратуре? Ядра становятся быстрее или медленнее?

Enthusiast ★★★
()
Ответ на: комментарий от Enthusiast

в среднем никак :) если ядро чтото заметно ускоряет, то об этом трубят везде %)
разработка в основном идет по пути увеличения стабильности.

pfg ★★★★★
()
Ответ на: комментарий от kaldeon

В файловой системе Bcachefs обновлён и стабилизирован формат дисковых структур. Любые дальнейшие изменения формата будут отнесены к категории необязательных и будут реализовываться в форме опциональных дополнений. Значительно повышена скорость проверки целостности ФС. Кроме того, в Bcachefs улучшена работа в режиме только для чтения; устранены проблемы, приводящие к обращению к памяти после её освобождения (use after free); решены проблемы c reflink-указателями в fsck; исправлена обработка перезапуска транзакции.

Ну как бы из этого следует, что как минимум из ядра не выкинули, патчи пишутся, прогресс мутится.

Хотя подробности узнать было бы интересно. Надеюсь, автор просто поупырил мел, и теперь всё нормально, как с другими ФС.

CrX ★★★★★
()
Ответ на: комментарий от Enthusiast

Что-то такое проскакивало год-другой назад. Но там вроде по жору памяти было в дефолте в каком-то дистре. Производительность не очень понятно как сравнивать. Например, если производительность какой-то ФС ускорили, а ты её не используешь, то ты этого не заметишь, а те кто использует — вполне могут. Если что-то с шедулерами перетрясли, то это может привести к одним результатам, например в серверных задачах, и к противоположным в десктопных, ну или там время выполнения какой-нибудь числодробилки вроде LZMA2 против «отзывчивости» — что считать «быстрее»?

Но какие-нибудь подробные и многосторонние исследования я бы тоже глянул, если есть.

CrX ★★★★★
()

поддержка чипов Qualcomm Snapdragon 8 Elite

Тестировал кто на ЛОРе? Ноутбуками можно теперь пользоваться, или это ещё не всё?

vsnb
()

Ну все, щас как сконпелирую! Мало не покажется!

Gonzo ★★★★★
()
Ответ на: комментарий от Enthusiast

очевидная эвристика что обычно происходит медленное плавное замедление ибо на фоне роста интегральной выч мощи(за счёт большего число потоков лучшести кэшей увеличение более близкой памяти и прочие +1.5% увеличение констант в коде не заметно )

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

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

qulinxao3 ★☆
()

«почти готовность к написанию реального драйвера на Rust»

Другими словами: «Не готов.»

Camel ★★★★★
()
Ответ на: комментарий от Enthusiast

Ядра становятся быстрее или медленнее?

Сжатие с zstd точно становится быстрее, когда в ядро принимают очередную версию.

dataman ★★★★★
() автор топика

Повышенапроизводительность механизмаMGLRU(Multi-Generational LRU), применяемый для определения какие страницы памяти используются, а какие можно вытеснить в раздел подкачки.

А ведь некоторые до сих пор сидят на старых ‘проверенных’ ядрах, чуть ли не 5.0, оставляя за бортом множество полезных фич.
Как-то писал, нравятся вам ваши ‘вылизанные’ ядра, не хотите гнаться за новыми актуальными ядрами, ну так хотя бы полезные патчи устанавливайте самостоятельно.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)

Ну вот, опять обновляться.

keeper_b ★★★★
()
Ответ на: комментарий от vsnb

Это чип для смартфонов/планшетов. В ноутбуках snapdragon x elite и пока всё сильно зависит от конкретного ноутбука.

WSL_user
()

Кто хочет ntsync в вайне погонять, может использовать aur wine-pure-git и такой хук, чтобы морды для вайна работали:

[Trigger]
Operation=Install
Operation=Upgrade
Type=Package
Target=wine-pure-git

[Action]
When=PostTransaction
Exec=/usr/bin/ln -sf /usr/bin/wine /usr/bin/wine64
steemandlinux ★★★★★
()
Ответ на: комментарий от kaldeon

На том что разработчики ядра работают на свою пенсию, а не на общее благо

cobold ★★★★★
()
Ответ на: комментарий от steemandlinux

И права 0777 не забудьте:

/etc/udev/rules.d/99-ntsync.rules

KERNEL=="ntsync", MODE="0777"

/etc/modprobe.d/ntsync.conf

ntsync

Можно это тоже в хук закинуть.

steemandlinux ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Его разработали уже давно и оно вроде уже было в каком-то рудиментарном виде в ядре. Я даже успел забыть нафига оно вообще нужно. Вроде ноги из CodeWeavers растут.

imul ★★★★★
()
Последнее исправление: imul (всего исправлений: 1)
Ответ на: комментарий от steemandlinux

В смысле? Насколько я знаю поддержка ntsync в wine уже давно. Другой разговор что не все дистры собирали модуль ядра ntsync сбоку …

mx__ ★★★★★
()

Хороший добрый спокойный релиз. Апгрейдиться или нет - вопрос, я лично сдаунгрейдил с 6.14-rc7 на 6.12.20 - немного подглючивает s0ix на моем железе.

Поддержка SpacemiT радует, думал прикупить их ноут но скачок цен и жаба остановили.

Но поддержка вменяемая Little-Big на x86 архитекутуре пока не случилась, равно как и новый графический драйвер XE не дозрел до выхода из состояния экспериментального (заслуженно - периодически подвисает на несколько секунд в неожиданых местах).

Qui-Gon ★★★★★
()
Ответ на: комментарий от Enthusiast

Ядра становятся быстрее или медленнее?

Ну попробуй запустить современное 6.14 на первом пне, где летало 2.4 :)

vasya_pupkin ★★★★★
()
Ответ на: комментарий от Enthusiast

Вроде похороникс вовсю этими тестированиями увлекается, можно закинуть идею тестировать ядра 6.14, затем -5 -10 -15 лет

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от steemandlinux

В 10.4 завезли. Раньше тоже все это можно было, и ntsync и патченный Wine от Фигуры. Эффект есть. Не 150%, но ощутимый, 120% точно.

Rolex ★★
()
Последнее исправление: Rolex (всего исправлений: 1)
Ответ на: комментарий от steemandlinux

Спорить не буду, но когда в январе заговорили про ntsync в 6.14, в инете было полно про него тестирование в разных популярных дистрах …

вот к примеру год назад в той же Нобаре, причем это было даже не в 40 версии а в 39.

https://www.reddit.com/r/linux_gaming/comments/1ce7z19/gaming_on_linux_ep131_ntsync_vs_fsync_nobara_39/?rdt=49199

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от Enthusiast

Говорят, стало быстрее. Надо ждать тестов от похороникса. Но можно и самому прогнать, например, вот это.

rupert ★★★★★
()

А у меня все ядра в диапазоне [6.6.44, 6.12.18] включительно периодически перегружают ноут (AMD Ryzen 9 7845HX). Сижу на 6.6.42. И если в этой новой вундервафле не пофиксили, то и нафиг она нужна.

dimgel ★★★★★
()

Ммм, тег rust теперь всегда будет преследовать ...

Myp3ik ★★★
()
Ответ на: комментарий от CrX

Производительность не очень понятно как сравнивать

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

drl
()
Ответ на: комментарий от Enthusiast

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

mx__ ★★★★★
()
Ответ на: комментарий от drl

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

eternal_sorrow ★★★★★
()
Ответ на: комментарий от CrX

Производительность не очень понятно как сравнивать

Согласен. Те, кого интересует производительность, меряют и сравнивают именно то, что им интересно. Слишком много критериев, зачастую частично противоположных, как low latency и high throughput.

blex ★★★
()
Ответ на: комментарий от Enthusiast

Кто-нибудь сравнивал производительность работы старых и новых ядер «Линукса» при одних и тех же настройках и при работе на той же самой электронной аппаратуре? Ядра становятся быстрее или медленнее?

ядро становится только быстрее

kto_tama ★★★★★
()
Ответ на: комментарий от MOPKOBKA

зачем мне MGLRU?

Это «must have» для 2025 года - никто уже не спрашивает зачем мне это, дефолтно пользуются и не могут нарадоваться.

Но, правда, еще остались ‘дремучие’ олды, которые тянут прогресс назад и цепляются за старое - "Нормально же сидели, чё началось то? ". :)

krasnh ★★★★
()
Ответ на: комментарий от krasnh

Как можно тянуть прогресс назад, просто не используя новое ядро? Да и в чем польза этих странных букв ABCDE, ой, MGLRU, я так и не понял.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)

Вот бы побольше проектов с такими крутыми обновлениями.

wandrien ★★★
()
Ответ на: комментарий от MOPKOBKA

Да и в чем польза этих странных букв ABCDE, ой, MGLRU, я так и не понял.

Улучшение производительности при нехватке оперативной памяти. Точнее, уменьшение ухудшения производительности.

Как можно тянуть прогресс назад, просто не используя новое ядро?

Фанатики, сэр.

wandrien ★★★
()
Ответ на: комментарий от wandrien

Фанатики

Как я и писал в исходном комменте, я не против старых проверенных ‘облизанных’ ядер у юзеров, если они самостоятельно добавляют полезные эффективные патчи, улучшающие производительность и удобство пользования системой. Но так ведь никто не делает, и старое проверенное ‘облизанное’ ядро, действительно старое, просто старое.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)

В каком дистре легко поставить чтоб не собирать руками?

cdtemp
()
Ответ на: комментарий от wandrien

Юзерам абсолютно по барабану

Так и думал что прицепишься к моей у фразе «я не против старых … ядер у юзеров», сразу похерив в чем-то интересное обсуждение. ) Извини, что так провокационно для тебя выразил мысль.

krasnh ★★★★
()
Ответ на: комментарий от wandrien

Ну е-мое, не первый год на ЛОРе и реакции старожилов плюс-минус уже известны. Так что моя вина, по сути, что свой коммент я сконфигурировал подобным образом.

krasnh ★★★★
()
Ответ на: комментарий от eternal_sorrow

Так то если винду открыть, то там приложения для заметок улучшают производительность, кому что производительность)

drl
()
Ответ на: комментарий от kto_tama

ядро становится только быстрее

хорошее начало для фантастической автобиографии :о)
а потом про палец добавить пару многозначительных многоточий :о)

sunjob ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.