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)
Ответ на: комментарий от Legioner

А вообще выделять память и не использовать это странно, просто надо исправлять такой софт.

Что плохого в выделении лишнего терабайта ВИРТУАЛЬНОЙ памяти?

Зачем исправлять софт? Ты понимаешь, что это 1. невозможно 2. ненужно ?

Какая разница, сколько выделено виртуальной? Для физической все равно есть ограничитель в виде киллера. Киллер позволяет централизованно настраивать приоритеты при убийстве.

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

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

@X512 тебя это тоже касается

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

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

Тогда как при наличии оверкоммита и киллера абьюзер будет убит.

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

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

значит будет повод научить их обрабатывать ошибки выделения

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

Если память не используется - значит её надо свопировать постепенно.

Неактивная память свопится, когда нет СВОБОДНОЙ.

Есть вариант, что свободная никогда не закончится - например, если у тебя 60 ГБ памяти.

Зачем тогда дёргать диск путем своппинга, если СВОБОДНОЙ памяти дохрена? Преждевременный своппинг - это преждевременная нагрузка на диск. Это даже хуже оверкоммита: от оверкоммита диск не страдает.

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

А вообще корни проблемы растут от overcommit-а

Какой проблемы? У меня оверкоммит в единице - можно выделять 30 терабайт спокойно. 12309 нет, система под стрессаими не виснет.

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

без overcommit-а ситуации, когда памяти не хватает вообще никак - не возникает в принципе а

cannot allocate memory

– это не нехватка памяти?

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

на время обновления системы компьютер становится «вещью в себе»

и сколько у тебя свопа? своп только на SSD?

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

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

страничный кеш забиваться не будет.

Толсто.

Вообще я думал, что в линуксе это сто лет назад пофиксили

Да, просто нужно чуть поправить дефолт для vm.dirty*

cp отработал быстро, а потом ещё данные реально пишутся полчаса

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

это кривая конфигурация системы

лечится ограничением vm.dirty* или записью в обход кэша

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

Кстати, надо бы их немного поднять обратно…

думаю нормальный вариант - это возможность сброса кэша за несколько сек. Если скорость запись на флешку 8М/s, то 32-64МБ - неплохое значение для dirty.

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

Меня лично напрягают все эти патчи

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

У меня он подключен, но толком не используется

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

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

Управление памятью и так кромешный ад

почему ад? вроде нет никаких проблем, если кодер и админ не идиоты.

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

Вполне нормально, всё же относительно. Вон просто выше смеётся, что это типа с 2.6 могло быть, а тут ба-бах с 4.10.

флешки ненужно!!!

Ну это классика.

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

Гном будет резервировать себе 2-3 гига про запас просто на случай «я же не должен работать без памяти, я же оболочка рабочего стола»

уже, пока 250 МБ

passing a memory protection of 250MiB

https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

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

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

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

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

Не получит. Окно создать заранее и спрятать. Можно ещё для окна зарезервировать память

Здраствуйте. Я, @X512. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова… Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы…

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

Вот сужий 12309:

Im having this bug for a long time, when i try to unarchive or copy big chunks from my USB HDD, after some time like after whole memory got cached, system starts to stutter. free -m shows all of the memory i have as cached and there is some swap activity. Disabling swap doesnt fix it. Please there are many people having this bug. And there are many kernel versions affected from it.

https://bugzilla.kernel.org/show_bug.cgi?id=210067

нашел элементарно в разделе https://bugzilla.kernel.org/buglist.cgi?component=Other&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Memory%20Management&query_format=advanced&resolution=---

думаю там таких репортов еще сотни лежат, если поискать

оправдывайтесь, 12309-диссиденты

anonymous
()

а вот и нерабочий киллер

 RmBeer 2020-09-07 06:26:52 UTC

Distro: Archlinux 5.6.10-arch1-1

The machine hangs when it reaches 100% memory usage.

To be more exact, the performance drops to 1hz speed, which means that you have to wait more than 1 hour for a bash script to be executed manually and kill all the possible processes involved that consume too much memory.
I don't have swap.
It has also already been tested with a swap file using a mounted loop, even if both fill to 100%, the machine hangs.
What gets filled is the memory used and not the buffer/cache.

Using a test code, it never returns an 'out of memory' or OOM Killer never responds:

https://bugzilla.kernel.org/show_bug.cgi?id=209185

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

И да, какие флешки в 2021 году? Сейчас же время облаков

Как вы ОС загрузите и установите из облаков? Как вы будете диагностировать и исправлять проблемы загрузки ПК?

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

При отсутствии оверкоммита могут падать случайные мелкие процессы, если начинают выделять память

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

В-четвертых прдавляющее большинство процессов не обрабатывают ошибки выделения - они просто падают, что не особо отличается от убийства киллером.

Линукс всегда отличался количеством говнокода.

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

Чувак не умеет писать багрепорты. Это уровень письма в техподдержку, но никакой техподдержки там нет и не будет.

post-factum ★★★★★
()
Ответ на: комментарий от X512

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

ну и нахрена мне система с падающими случайными процессами? с нормальным киллером падают жирные или те, у кого высокой оом скор

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

ну и нахрена мне система с падающими случайными процессами?

Правильно. Переходи на Windows. Одобряю твой выбор.

fsb4000 ★★★★★
()
Ответ на: комментарий от post-factum

Что еще он должен был уточнить? типа версию ядра, конфиг vm?

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

Оверкоммит победил, смиритесь.

Ничего он не победил. В Windows 1.0 - 10 (основная платформа десктопных приложений в том числе для дизайнеров, инженеров и прочих производителей контента) нет никакого оверкоммита, программы обрабатывают ошибки выделения памяти. Там даже есть инструмент тестирования, вызывающий случайные ошибки выделения памяти, так что не сложно распознать говнокод.

В Mac OS тоже нет такого убогого оверкоммита как в Линуксе.

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

ну и нахрена мне система с падающими случайными процессами?

Пишите баг репорты авторам этих падающих процессов.

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

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

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

Нет пусть всё виснет намертво или будут убиваться ни в чём невинные процессы без шанса обработки ошибок.

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

Пишите баг репорты авторам этих падающих процессов.

В Linux этим принято гордиться, а не считать багом :(

Вот программист twitch рассказывает как выделяет лишних 10 гигабайт, и у него лучше работает GC на go после этого. И говорит не парьтесь ребята, overcommit рулит

https://blog.twitch.tv/ru-ru/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/

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

не неси чепуху, с оверкоммитом ничего не виснет

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

Ну и в чем он неправ? Как раз показал, что оверкоммит - отличная вещь, и дал понять, что противники оверкоммита - поехавшие.

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

Чувак не умеет писать багрепорты

как это отменяет зарепорченный баг? чувак описал симптомы 12309.

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

Нет пусть всё виснет намертво

УМВР.

или будут убиваться ни в чём невинные процессы без шанса обработки ошибок.

В твоей модели отказа выделить память случайному процессу? Да.

С оверкоммитом? Нет.

Заканчивай жить в фэнтезийном мире.

Я даже примерно представляю, как ты в нём очутился. Многие когда-то были такими же наивными. Сочувствую, серьёзно.

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

У меня сборка больших пакетов только так и вытягивается. g++ жрёт память как не в себя и когда это поправят - неизвестно.

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

Вот удалят твой файл из облака, потому что он что-то там нарушил, будешь знать.

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

g++ жрёт память как не в себя и когда это поправят - неизвестно.

Отправляй патчи. Этож опенсурс и свобода. Каждый может поправить багованную программу, а не только первоначальный автор :) Или Столману напиши, пускай он правит. Он же когда-то gcc начал…

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

Отправляй патчи.

Зачем если есть Clang, который прекрасно работает? Разобраться в исходниках Clang намного проще чем GCC.

Когда я делал порт Haiku на RISC-V, я столкнулся с несколькими откровенными багами, из-за которых генерировался битый код с прыжками не пойми куда (починено отключением специфической оптимизации линковщика). Также там есть различное нежелательное поведение, например для leaf-функций некорректно генерируется стековый фрейм с указателем на цепочку фреймов (-fno-omit-frame-pointer), в результате получается битый вывод стека вызовов в отладчике ядра. В Clang таких проблем нет.

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

я делал порт Haiku на RISC-V

какой смысл портировать такие устаревшие ОС на новые процессоры ? там ничего не работает и вид из 90-х как у win 3.1. Сейчас есть Fuchsia - там фактически собраны все передовые наработки.

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

Тринадцать несчастливое число

Ну так запиши его в двоичной системе счисления, и станет спокойнее…

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

устаревшие ОС

Линукс во многом основан на куда более устаревших технологиях. Haiku была спроектирована позже Линукса.

вид из 90-х как у win 3.1

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

Сейчас есть Fuchsia

Оно в текущем виде для десктопа пригодно ещё меньше, чем Haiku.

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

Не получит. Окно создать заранее и спрятать. Можно ещё для окна зарезервировать память, например просто выделить блок памяти «якорь», и освобождать его в ситуации нехватки памяти. Когда ситуация нехватки закончилась, вернуть якорь обратно.

еще не начали писать программу, а уже принялись лепить костыли.

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

Линукс во многом основан на куда более устаревших технологиях

но его не надо портирован - он и так в каждом утюге

Мне не нужны свистелки и перделки с анимациями и спецэффектами окон

ты даже кино в каком-то 4к не сможешь посмотреть, про 8к и больше или стерео можешь забыть, в общем про любые современные технологии можешь не вспоминать

Оно в текущем виде для десктопа пригодно ещё меньше, чем Haiku

Haiku никогда не была и не будет пригодна ни для чего, это фетиш как нюхательные трусы

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

ты даже кино в каком-то 4к не сможешь посмотреть

УМВР.

про 8к и больше или стерео можешь забыть

У меня такого монитора на данный момент нет, так что пока не требуется.

И это никак не связано с дизайном интерфейса. Никто не мешает сделать аппаратное ускорение видео в интерфейсе «в стиле Win 3.1».

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

Что плохого в выделении лишнего терабайта ВИРТУАЛЬНОЙ памяти?

Плохо то, что это просто бессмысленное действие.

Но на самом деле я не против виртуальной памяти, как таковой. Я против того, что это режим по умолчанию. Пускай будет у mmap какой-нибудь флаг OVERCOMMIT, если очень хочется. И если памяти на очередное выделение физической памяти не хватит, то конкретно это приложение будет пристрелено, по аналогии, что оно попросило сделать malloc, тот вернул null и оно abort сделало. Но это должно быть редкостью, если вдруг алгоритмы написаны так, что угодно пользоваться терабайтом виртуальной памяти. Чаще всего просто пишут malloc, который выделяет память (я в курсе, что упрощаю, не суть) или возвращает NULL. Всё.

Зачем исправлять софт? Ты понимаешь, что это 1. невозможно 2. ненужно ?

Я не понимаю, что это невозможно. Ты понимаешь, что даже в винде каждый драйвер при WHQL тестировании проверяется на режим работы при нехватке памяти? В Linux нет аналога WHQL, но, уверен, там ровно так же каждый драйвер аккуратно пишется, чтобы ядро не падало при нехватке памяти. Если ядро так могут писать, почему юзерспейс так писать не могут? Я не вижу ни одной причины, по которой это было бы невозможно.

Какая разница, сколько выделено виртуальной? Для физической все равно есть ограничитель в виде киллера. Киллер позволяет централизованно настраивать приоритеты при убийстве.

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

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

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

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

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

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

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