LINUX.ORG.RU

Linux 5.13

 , , ,

Linux 5.13

2

1

Линус Торвальдс анонсировал новую версию ядра Linux 5.13, отдельно подчеркнув, что это самый большой релиз по количеству проделанной работы!

После седьмого релиз-кандидата у нас была довольно спокойная неделя, и я не вижу причин откладывать релиз версии 5.13. Изменений за последнюю неделю мало, всего 88 коммитов не считая слияний (и некоторые из них просто откаты). Это не особо важные исправления и поскольку их мало, я предлагаю людям просто просмотреть прилагаемый список изменений, чтобы узнать, что произошло. В целом в 5.13 очень много изменений. Фактически, это один из самых крупных релизов 5.х с более чем 16 тысячами коммитов (более 17 тысяч, если считать слияния) от более чем 2 тысяч разработчиков. Однако, все эти изменения затронули всё и понемногу, поэтому трудно выделить что-то одно…

Наиболее значимые изменения:

  • LSM-модуль Landlock для дополнительного ограничения процессов (подробности);
  • возможность сборки в Clang с защитой CFI (Control Flow Integrity) (подробности);
  • рандомизация стека ядра для каждого системного вызова;
  • поддержка одновременного сброса TLB;
  • поддержка чипов М1 (пока на начальной стадии);
  • поддержка новых GPU от Intel и AMD;
  • возможность прямого вызова функций ядра из BPF-программ (подробности);
  • виртуальное звуковое устройство на базе virtio;
  • multi-shot режим в io_uring.

Небольшая статистика в цифрах:

  • принято патчей – 17189 (2150 разработчиков);

  • изменено файлов – 12996 ;

  • добавлено строк кода – 794705;

  • удалено строк кода – 399590;

  • общий размер патча – 60МБ.

  • 47% – драйверы устройств;

  • 14% – специфические для аппаратных архитектур;

  • 13% – сетевой стек;

  • 5% – файловые системы;

  • 4% – подсистемы ядра.

Одновременно c релизом ядра 5.13, латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 5.11 – Linux-libre 5.11-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В новом выпуске проведена чистка драйвера comedi. Прекращена чистка драйверов cyclades, isicom tty и i2400m wimax, которые были удалены из ядра. Обновлён код чистки блобов в драйверах и подсистемах amdgpu, i915 csr, r8152 usb, mhi bus, x86 touchscreen и qualcomm arm64.

Дисковая подсистема, ввод/вывод и файловые системы

  • Для файловой системы SMB3 реализована опция монтирования rasize, при помощи которой можно определить размер окна упреждающего чтения (readahead) для увеличения производительности некоторых видов нагрузки.
  • В файловой системе ext4 обеспечена перезапись элементов каталогов при удалении файлов, чтобы гарантировать, что имена удалённых файлов будут очищены. За счёт упреждающей загрузки битовых карт блоков повышена производительность кода для выделения блоков на недавно примонтированных ФС. В ext4 также разрешено одновременное использование режима работы без учёта регистра символов и шифрования.
  • В файловой системе exFAT добавлена поддержка ioctl-команды FITRIM (discard), для информирования накопителя о неиспользуемых в ФС блоках.
  • В файловой системе XFS добавлена возможность изъятия места из последней группы распределения в ФС, что стало первым звеном в реализации функции уменьшения размера существующих разделов с ФС XFS. Внесено несколько оптимизаций производительности.
  • В файловой системе Btrfs добавлено использование упреждающего чтения в команде send, позволившая сократить время полной отправки на 10%, а инкрементальной на 25%. Для зонированных блочных устройств обеспечено автоматическое фонового перераспределения зон при превышении порога в 75% неиспользуемого пространства.
  • В файловую систему EROFS (Enhanced Read-Only File System) добавлена поддержка режима big pcluster, позволяющего значительно увеличить производительность сжатия данных.
  • Добавлен новый системный вызов quotactl_path, который отличается от quotactl тем, что позволяет управлять квотами не через файл специального устройства, а через указание пути к точке монтирования ФС.
  • В механизме fanotify расширены возможности, доступные непривилегированным пользователям. Например, по аналогии с inotify без прав SYS_CAP_ADMIN теперь можно отслеживать события OPEN, ACCESS, MODIFY и CLOSE для файлов и каталогов.
  • В распределённой файловой системе OrangeFS (продолжение развития PVFS) реализована поддержка операций упреждающего чтения, позволивших существенно увеличить производительность операций чтения (в тестах пропускная способность возросла с 21.8 MB/s до 386 MB/s).
  • Повышена масштабируемость хэширования Device Mapper за счёт перехода на rbtree. В dm-integrity добавлена поддержка операции discard.

Память и системные сервисы

  • Добавлен новый контроллер cgroup – «Misc» (CONFIG_CGROUP_MISC), предназначенный для ограничения и отслеживания скалярных ресурсов, которыми можно управлять с использованием простого счётчика и ограничивать, задавая максимально допустимые значения. В качестве примера применения нового контроллера cgroup упоминается управление идентификаторами адресного пространства, применяемыми в механизме AMD SEV (Secure Encrypted Virtualization).
  • В интерфейсе асинхронного ввода/вывода io_uring для запросов POLL реализован режим multi-shot, при котором POLL не удаляется после генерации события, а остаётся активным и может генерировать несколько событий.
  • Из realtime-ветки ядра перенесён код, обеспечивающий обработку программно генерируемых прерываний в потоках ядра, что позволяет вытеснять их более приоритетными процессами.
  • Добавлена внутренняя библиотека netfs, в которую вынесены типовые функции, используемые в сетевых файловых системах.
  • Для архитектуры PowerPC реализована поддержка пространств имён для времени (time namespaces), позволяющих использовать в контейнере своё время.
  • Для архитектуры RISC-V реализована поддержка kexec, crash dump, kprobe и запуска ядра по месту (execute-in-place, выполнение с исходного носителя, без копирования в ОЗУ).
  • В BPF-программах трассировки появилась возможность использования локального для задачи хранилища данных task-local storage, обеспечивающего более высокую производительность за счёт привязки данных к конкретному BPF-обработчику.
  • Реализован новый механизм для прямого вызова функций ядра из BPF-программ, который уже использован в реализации алгоритмов перегрузки TCP. Для обеспечения безопасности вызываемые функции должны быть явно определены в белом списке.
  • В систему трассировки функций ftrace добавлена опция func-no-repeats, позволяющая отразить повторяющиеся последовательные вызовы функции в виде счётчика.
  • В системный вызов userfaultfd(), предназначенный для обработки page faults (обращение к невыделенным страницам памяти) в пространстве пользователя, добавлена возможность управления частичными fault-ами, при которых страница памяти присутствует, но нет записи в таблице страниц памяти.
  • Прекращена поддержка специального файла /dev/kmem, при помощи которого можно получить доступ ко всему адресному пространству ядра. Данный файл признан устаревшим и создающим проблемы с безопасностью.
  • Для чипов Intel реализован новый драйвер для управления охлаждением, позволяющий снижать частоту процессора при опасности перегрева. В отличие от имеющегося механизма активации TCC (Thermal Control Circuit), новый драйвер манипулирует относительными значениями, т.е. может снизить частоту на этапе начала значительного роста температуры, не дожидаясь преодоления порогового критического значения.
  • Реализована возможность одновременного сброса локального и внешнего буферов ассоциативной трансляции (TLB), которая привела к увеличению скорости прохождения теста Sysbench на 1-4%.

Виртуализация и безопасность

  • В состав включён LSM-модуль обеспечения изоляции приложений Landlock, позволяющий ограничить взаимодействие с внешним окружением группы процессов и разработанный с оглядкой на такие механизмы изоляции как XNU Sandbox, FreeBSD Capsicum и OpenBSD Pledge/Unveil. Логика предоставления доступа определяется при помощи BPF-программы, но в отличие от seccomp-bpf, Landlock не фильтрует системные вызовы и их аргументы, а позволяет ограничить использование объектов ядра, таких как иерархии файлов. При помощи Landlock любой процесс, в том числе непривигелированный, может надёжно изолировать себя и не допустить обхода изоляции в случае выявления уязвимостей или вредоносных изменений в приложении. Landlock позволяет процессу создать защищённые изолированные окружения, реализованные в форме дополнительного слоя над существующими системными механизмами управления доступом. Например, программа может запретить доступ к файлам за пределами рабочего каталога.
  • Добавлена возможность рандомизации смещений в стеке ядра при обработке системных вызовов с целью усложнения атак на стек. Суть предложенной защиты в выборе случайного смещения стека при каждом системном вызове, что усложняет определение раскладки стека в памяти даже в случае получения информации об адресах, так как при следующем системном вызове базовый адрес стека изменится. Для включения рандомизации предложены параметр командной строки ядра randomize_kstack_offset=on/off и настройка CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. Накладные расходы оцениваются приблизительно в 1% потери производительности.
  • Добавлена поддержка сборки ядра с включением в компиляторе Clang механизма защиты CFI (Control Flow Integrity), добавляющего перед каждым косвенным вызовом функции проверки для выявления некоторых форм неопределённого поведения, которые потенциально могут привести к нарушению нормального порядка выполнения (control flow) в результате применения эксплоитов, изменяющих хранимые в памяти указатели на функции. Для включения CFI предложен параметр CONFIG_CFI_CLANG.
  • В предоставляемом ядром сервисе хранения ключей шифрования (key ring) механизм доверительных ключей (Trusted Keys) теперь охватывает не только ключи из TPM-модулей, но и из окружений TEE (Trusted Execution Environment). Для управления источником доверительных ключей предложен загрузочный параметр trusted.source. Кроме того, добавлена возможность обработки доверительных ключей в формате ASN.1. Добавлен параметр для упреждающей загрузки списка отозванных сертификатов во время загрузки ядра. Решена проблема CVE-2020-26541 с игнорированием в чёрном списке UEFI Secure Boot сертификатов, поставляемых в формате EFI_CERT_X509_GUID, что позволяло загрузить систему с отозванным сертификатом.
  • В криптоподсистему ядра добавлена поддержка проверки цифровых подписей ECDSA на базе эллиптических кривых. Реализована возможность верификации политик SELinux при помощи подсистемы IMA (Integrity Measurement Architecture), обеспечивающей поддержание базы хэшей для проверки целостности данных.

Сетевая подсистема

  • Удалена поддержка технологии WiMAX, которая уже не используется в публичных сетях, а в ядре единственным драйвером с которым можно использовать WiMAX остаётся устаревший драйвер Intel 2400m. В сетевом конфигураторе NetworkManager поддержка WiMAX была прекращена в 2015 году. В настоящее время WiMax практически полностью вытеснена такими технологиями, как LTE, HSPA+ и Wi-Fi 802.11n.
  • Добавлен драйвер для сетевого адаптера MANA (Microsoft Azure Network Adapter).
  • В драйвер ath11k добавлена поддержка беспроводных модулей Qualcomm QCN9074 с поддержкой 802.11ax.
  • В драйвере iwlwifi реализована возможность пассивного сканирования каналов в диапазоне 6GHz.
  • Проведена оптимизация подсистемы XDP (eXpress Data Path), позволяющей манипулировать сетевыми пакетами на стадии до их обработки сетевым стеком ядра Linux. Проведённые тесты демонстрируют увеличение производительности XDP на 4-8%. Для устройств virtio прирост производительности программной обработки AF_XDP может достигать 33%.
  • В ICMP реализована поддержка расширенных PROBE-сообщений, определённых в RFC 8335.
  • Продолжена интеграция в ядро MPTCP (MultiPath TCP), расширения протокола TCP для организации работы TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. В новом выпуске добавлена поддержка sockopt для задания типовых опций TCP. Реализована возможность сброса отдельных подпотоков (subflow).
  • В netfilter добавлена поддержка управления ресурсами при помощи унифицированной иерархии cgroups v2.
  • В ethtool реализован интерфейс для чтения статистики IEEE MIB с поддержкой mlx5 и bnxt. Сетевым драйверам разрешено извлечение произвольных данных из SFP EEPROM, манипулируя не связкой смещение+размер, а страницами памяти.

Оборудование

  • Реализована начальная поддержка ARM-чипа Apple M1, охватывающая контроллер прерываний, таймер, UART, SMP, функции для организации ввода/вывода и MMIO. Обратный инжиниринг GPU пока не завершён, для организации вывода предоставляется поддержка фреймбуфера и консоли через последовательный порт.
  • Продолжена чистка ядра от старых драйверов, удалены драйверы gasket (Google ASIC), sysace, umem и несколько старых драйверов для последовательных портов.
  • После 13 лет нахождения в ветке staging стабилизирован и перенесён в основной состав драйвер comedi для поддержки устройств сбора данных.
  • Добавлен драйвер GUD (Generic USB Display) с реализацией базового драйвера для экранов и TV-адаптеров, подключаемых через интерфейс USB. Драйвер предоставляет DRM-свойства (Direct Rendering Manager) для поворота изображения, управления яркостью, доступа к EDID, настройки видеорежимов и подключения TV, которые могут использоваться в качестве основы для создания драйверов для конкретных устройств.
  • Добавлена поддержка процессора Loongson-2K1000, включающего два ядра MIPS64r2.
  • Добавлен звуковой драйвер virtio с реализацией виртуального звукового устройства, которое можно использовать в гостевых системах для вывода и записи звука без проброса доступа к звуковой карте и без эмуляции.
  • В драйвере amdgpu добавлена начальная поддержка GPU Aldebaran (gfx90a). Включена начальная поддержка технологии адаптивной синхронизации FreeSync для HDMI (ранее была доступна для DisplayPort), которая позволяет корректировать частоту обновления информации на экране. Включена поддержка ASSR (Alternate Scrambler Seed Reset). Добавлен ioctl для запроса возможностей, связанных с кодированием и декодированием видео. Добавлен режим CONFIG_DRM_AMD_SECURE_DISPLAY для обнаружения изменений в дисплеях, отображающих критически важную информацию. Добавлена поддержка механизма энергосбережения ASPM.
  • В драйвере i915 для видеокарт Intel включена поддержка чипов Intel Alderlake-S. Добавлена поддержка eDP MSO (Embedded DisplayPort Multi-SST Operation).
  • Добавлена поддержка игрового контроллера Luna (Amazon), а также сенсорных экранов Hycon HY46XX, ILITEK Lego Series и MStar MSG2638.

Перевод изменений взят с сайта Opennet, ссылка на новость: https://www.opennet.ru/opennews/art.shtml?num=55397

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

★★★★

Проверено: Shaman007 ()
Последнее исправление: claire (всего исправлений: 6)

Ответ на: комментарий от anonymous

Демон перезапустится, очевидно

Так а если памяти нет, а демон в юзерспейсе..

Но такого ни разу не наблюдалось: демон небольшой, имеет обычно нулевой скор, во-вторых сам срабатывает оперативно.

А ну ок, понятно что скорее всего такого не случится, но все равно костыль же без гарантий.

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

Я жду патчей из pf в ванилле

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

anonymous
()
Ответ на: комментарий от tfeartx

Очевидно, что мелкий демон не может быть убит раньше, чем крупные процессы.

А ну ок, понятно что скорее всего такого не случится, но все равно костыль же без гарантий.

А где гарантия, что космическая частица не пролетит через процессор и не завесит его? Явления где-то одного порядка.

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

костыль же без гарантий

У ядерного киллера гарантий еще меньше - его вообще хрен дождешься.

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

Очевидно, что мелкий демон не может быть убит раньше, чем крупные процессы.

Угомонись уже, я же сказал что ты победил и унизил меня. Только не пиши такого больше про оом =)

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

Сам угомонись. Вспомни, как по дефолту ядерный oom killer работает, если не твикать его. Как ты добьешься смерти мелкого демона на дефолте?

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

Во-вторых убивать процессы пользователя это просто вредительство

Ты мог бы это повторить в глаза людям, которые страдают от зависаний при нехватке памяти?

Да, конечно. @Legioner абсолютно прав: агрессивный отстрел процессов — это безумие.
Нормальное работающее решение, селективно давящее на тяжёлые процессы известно давно: это cgroups.

Выпуск earlyoom 1.3, процесса для раннего реагирования на нехватку памяти (комментарий) (вниз, и по ссылкам)

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

Да, конечно. Legioner абсолютно прав: агрессивный отстрел процессов — это безумие.

Нормальное работающее решение, селективно давящее на тяжёлые процессы известно давно: это cgroups.

Это совершенно разные механизмы, решающие разные и в чем-то противоположные задачи.

cgroups нужен, чтобы огородить известный сет процессов. А киллер — чтобы не допустить зависона при случайной мисконфигурации или из-за утечки памяти в любом нормально-нетяжелом процессе.

Поясни, что ты называешь агрессивным отстрелом процессов.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от Eddy_Em

Юзайте freebsd, в ней такого бага нет. Вон уже два года юзаю как десктоп - ничем не хуже линукса, а местами ГОРАЗДО лучше и продуманней.

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

Я называю безумием убийство задач, которые могут быть выполнены используя доступные память+своп.

cgroups нужен, чтобы огородить известный сет процессов. А киллер — чтобы не допустить зависона при случайной мисконфигурации или из-за утечки памяти в любом нормально-нетяжелом процессе.

В идеале, да: нужно знать, где подстелить.
Но на практике с cgroups прокатывает и старейший трюк размена throughput на latency: жёсткий потолок на память для всего юзерспейса.

Система продолжит ворочаться в своих (скажем) 20% памяти, у юзера останется возможность решать, что делать дальше: стрелять, выделять в отдельную группу и душить, и т.д.

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

А куда мне заплатить, чтоб получить десктопный дистр без гарантированного 12309?

Тебе уже дали бесплатное решение: ограничивай dirty_bytes. Или ты из тех, кто доверяет только платным решениям?

если 12309 в каком то дистре решили

В каком решили? В федоре исправляли не 12309, а немножко другую проблему - высокие задержки при нехватке памяти.

зачем хакавлад корячится тогда со своими патчами

Потому что

The kernel does not have a mechanism for selectively protecting clean file
pages. A certain amount of the CFP is required by the userspace for normal
operation. First of all, you need a cache of shared libraries and
executable files. If the volume of the CFP cache falls below a certain
level, thrashing and even livelock occurs.

Protection of CFP may be used to prevent thrashing and reducing I/O under
memory pressure. Hard protection of CFP may be used to avoid high latency
and prevent livelock in near-OOM conditions. The patch provides sysctl
knobs for protecting the specified amount of clean file cache under memory
pressure.

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

anonymous
()
Ответ на: комментарий от aidaho

селективно давящее на тяжёлые процессы известно давно: это cgroups

Где готовый рецепт для cgrouop_v2?

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

Каким ты видишь правильное поведение системы при нехватке памяти?

Глазами cgroups: тяжёлый процесс упирается в лимит памяти и в индивидуальном порядке идёт свопиться. Там он на ходу упирается в лимиты по i/o и троттлится до безобидного состояния.
Будет выполняться долго, упорно, но незаметно.

Я так пару дней назад запускал жирноту, которая нуждалась в 45Гб памяти.

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

Там он на ходу упирается в лимиты по i/o и троттлится до безобидного состояния.

Это ж пердольское красноглазое решение, не? Как ты представляешь подобное для внедрения из коробки, например, в федора?

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

Где готовый рецепт для cgrouop_v2?

Наврное ты же это и спрашивал раньше.
Ответ тот же: нет желания переписывать работающую конфигурацию на v2 просто «потому что».
Вот выпилят v1, тогда можно начинать шевелиться.

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

тяжёлый процесс упирается в лимит памяти и в индивидуальном порядке идёт свопиться. Там он на ходу упирается в лимиты по i/o и троттлится до безобидного состояния. Будет выполняться долго, упорно, но незаметно.

Я думаю аналогично.

Но мне не нравится, что для этой цели на общесистемном уровне приходится задействовать cgroups. Если поиграться с упомянутым выше protecting clean file pages и алгоритмами селективного удушения процессов при выгрузке их анонимных страниц, можно добиться подобного эффекта по умолчанию.

То есть такой юзкейс: чтобы процесс, который требует 45Гб памяти, не препятствовал работе sshd, когда тот просыпается от спячки на сокете. Даже если через параметры cgroups вообще ничего не настроено.

За компанию это решит также вечный призрак 12309.

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

И ты называешь это хорошим решением? Да это же безумное красноглазие.

zram+le9 дают возможность иметь живой гуй под сильными нагрузками, так что и без троттлинга норм. https://github.com/hakavlad/le9-patch#demo

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

Если там systemd внедрили впереди планеты всей, то в чём проблема?
Тот же systemd уже распихивает процессы одного пользователя в отдельную группу.
Хоть завтра можно в пол-дыхания поставить ковровый лимит на группу и дать юзеру возможность прыгнуть по Ctrl-Alt-Fn в терминал из любой 12309 жопы.

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

Мне нафиг не нужно ничего из вышеперечисленного! Я хочу, чтобы «из коробки» все работало!!! Зачем мне дыры по умолчанию?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от fooser

Не годится: у фряхи огороженная лицензия, не GPL!

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

Но мне не нравится, что для этой цели на общесистемном уровне приходится задействовать cgroups.

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

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

Я хочу, чтобы «из коробки» все работало!!!

купи мак

Зачем мне дыры по умолчанию?

установи обновления

и где ты там дыры увидел?

У тебя тоже лапки, что ты не в состоянии выполнить элементарные настройки?

anonymous
()
Ответ на: комментарий от aidaho

Повторю вопрос:

Как ты представляешь подобное для внедрения из коробки, например, в федора?

И твой ответ:

Если там systemd внедрили впереди планеты всей, то в чём проблема?

В том, что ты не описал, как это должно работать ИЗ КОРОБКИ? Какой размер лимитов ставить? Объемы памяти разные в разных системах, разная конфигурация сигрупп. Какой группе сколько дать? Что они должны внедрять? Ты сказал что решение есть, но не описал его.

anonymous
()
Ответ на: комментарий от Eddy_Em

А почему в дефолтном ядре нельзя это сразу же сделать?

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

Что касается ядер дистрибутивов, то и убунта - не чисто десктопная ос.

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

anonymous
()
Ответ на: комментарий от Eddy_Em

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

anonymous
()
Ответ на: комментарий от Eddy_Em

Покажи мне свежий баг-репорт по поводу 12309. Он у кого-то еще есть? Я не вижу репортов в багзиллах по поводу этого бага.

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

Я приводил свой конфиг из до-systemd-времён раньше, мне просто всё сложнее его находить гуглом:

cgroups, systemd и распределение процессора.

Он без изменений работает для меня по сей день, лет пять уже.

Если сам не можешь, то проси systemd-гуру прикостылить и опакетить юнит, который поставит юзер-группе лимиты на память и i/o.
Ковровый лимит на всю группу по минимуму убережёт от полного лока, когда юзерспейс пойдёт трешиться от нехватки памяти.

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

агрессивный отстрел процессов — это безумие

селективно давящее на тяжёлые процессы

Так в итоге ж все равно тяжелые процессы будут убиты, своп не бесконечен. Не противоречишь ли себе?

anonymous
()
Ответ на: комментарий от tfeartx

поддержка чипов М1 (пока на начальной стадии);

Спасибо всем разработчикам за их неоценимый вклад, здоровья всем этим этим людям и семьям, пусть Господь благословит их и дарует много детишек и радости в жизни. Но может быть уже починят нормально i2c тачпады, бл&ть???

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

проси systemd-гуру прикостылить и опакетить юнит

Допустим, я и есть тот самый системд-гуру

юнит, который поставит юзер-группе лимиты на память и i/o

Какой именно юзер-группе? Всему user-1000.slice?

убережёт от полного лока, когда юзерспейс пойдёт трешиться от нехватки памяти

так с le9 и трешинга-то не будет - это решает корень проблемы.

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

Я так понял, у вас, системдшников, уже не линукс, а своя собственная операционная система? Эдакий клоун андроида?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

Процесс, которому хватает ram+swap должен выполниться. А тот, которому не хватает — не должен. Ничего другого не обещал.
Хотя есть и такая штука, как swapspace, которая пытается обещать и второе.

Юзерспейс-киллеры хватаются за дробовик не когда нехватает ram+swap, а когда им кажется, что пора.
Они в принципе своём отрицают, что компьютер нужен для решения задач, и если задача поставлена, нужно искать способы её выполнить.

Вместо этого, они задачи расстреливают. Безумие.

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

Безумие

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Ну вот представь, что у тебя числодробилка трое суток тихо мирно насиловала компьютер, синтезируя изображение из апертуры нескольких радиотелескопов.
А потом техник подвигал мышкой, и попытка поднять с диска страницы, нужные для отображения десктопа, триггернула васян-киллера.
И всё, трое суток коту под хвост.

А если бы не подвигал, то через часов пять бы отработало. Вот такой офигенный детерминизм. Нравится?

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

Я разве ж против? Пусть процесс тормозит, но работает, и пусть у пользователя будет выбор, что делать дальше.

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

представь

Такие числодробилки я запускаю на сервере с ограниченным доступом. И там иксов вообще нет! А вообще, вспоминаю как лет 20 назад, чтобы мне записать DVD-болванку, один товарищ выдергивал из компа ethernet-шнурок, закрывал все открытые окна и лишь потом записывал ☺

Пусть процесс тормозит, но работает

В таком случае было бы идеальным выгрузить особо жрущий процесс в своп и отправить в спячку, а юзер пусть сам убивает лишнее. Правда, свопа придется немерено выделят: скажем, если оперативки 128ГБ, то свопа придется с полтерабайта (если еще и хочешь sleep)…

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от aidaho

Окей, вот решение для сигруп2: https://github.com/hakavlad/memavaild

Зачем нужен целый демон вместо простого выставления лимита для слайса юзера?

Потому что system.slice может разжиреть тоже, и выжрать память.

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

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

anonymous
()
Ответ на: комментарий от aidaho

Процесс, которому хватает ram+swap должен выполниться. А тот, которому не хватает — не должен

но ведь все процессы живые, и им всем нужны ресурсы - всем до единого.

тот, которому не хватает — не должен

Так киллеры это же и делают. Хотя нет. Они убивают процессы, которым хватает памяти, а твои лимиты ограничивают процессы, которым не хватает памяти, да?

Наши аккуратные лимиты и их кровожадные киллеры.

Но эффект-то в итоге один: кто-то будет убит (процесс, которому хватало памяти, но вдруг перестало хватать).

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

Потому что system.slice может разжиреть тоже, и выжрать память.

Теоретически, да.

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

На практике, та статика, которую я себе налабал на коленке пять лет тому назад, сделала отвесное пике в трешинг невозможным.
Даже на моём sony vgn-p с несчастными 2Гб оперативки и доисторическим ssd.

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

aidaho ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.