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

Я это всё читал сто лет назад и про всё это в курсе.

Legioner ★★★★★
()

Параллельный tlb flush звучит интересно. Жаль в 6й редхат не портируют.

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

Приложение: Хочу копировать 8 гигов.

Что за системный вызов? Приложение копирует по 4-8 КБ за один write. Никто не копирует 8 гигов.

Поэтому тут всё в принципе и заканчивается. 4 КБ попросили записать, 4 КБ флешка записала, сказала «ОК», write вернулся, пошли дальше.

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

Желательно на btrfs. Он у меня знатно убивал древний ноут с 2 гб памяти. Пришлось откатиться на ext4.

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

Что за системный вызов? Приложение копирует по 4-8 КБ за один write. Никто не копирует 8 гигов.

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

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

У меня не генту, я не хочу ради эксперимента ставить миллион dev пакетов.

dd if=/dev/zero of=/mnt/hdd/bigfile bs=8192 count=$((10 * 1024 * 1024))

Вот запустил 80 ГБ записи. Вообще никакой реакции, всё как работало, так работает.

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

Поэтому тут всё в принципе и заканчивается. 4 КБ попросили записать, 4 КБ флешка записала, сказала «ОК», write вернулся, пошли дальше.

А говоришь, что читал что-то…

Ядро откладывает запись сколько может. Никто блоками по 4 КБ не пишет.

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

Копируют вызовом write, mmap это другое.

«Вы не понимаете, это другое» (c)

Какая разница, каким способом забивать страничный кэш? Данные всё равно осядут в нем перед сбросом на диск.

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

Ядро: Окей, записываю 8 гигов в страничный кэш.

You are doing it wrong. Потом кеш чтения будет вытеснен и всё начнёт страшно тормозить.

Флешка: Извиняйте, это минут на пять.

Эта информация доступна заранее и ядро её может учитывать. И вообще железо не даёт никаких гарантий скорости работы.

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

Разница в том, что никто в своём уме файлы через mmap не копирует. Но в целом разницы, думаю, не будет, просто пишущий подвиснет, пока флешка не прожуёт данные. А страничный кеш забиваться не будет.

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

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

Реально, почитайте, как устроена виртуальная память. Какой кеш чтения? Запусти, на худой конец, top или free. Нету никаких чтения / записи.

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

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

А это как коммунизм, сколько не фикси, а что-то не работает. Видимо, место проклятое.

Вот патч, который выше в теме обсуждали — это еще один подход к той же штанге. Может быть, на этот раз окончательный.

Я помню, что раньше в линуксе такая проблема была - cp отработал быстро, а потом ещё данные реально пишутся полчаса, но это кривая конфигурация системы, просто mount должен с опцией sync делаться и всё, проблемы нет.

Я чтобы не париться с опциями монтирования, просто задал низкие значения для vm.dirty_bytes, vm.dirty_background_bytes.

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

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

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

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

Это на linuxmint 20.04. Разбираться пока не стал, всё равно его сносить в пользу kubuntu буду. 😎

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

отмонтирование опциональное по сути

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

beck ★★★★
()

Чё-то NFS-шары не монтируются с сервера с этим ядром.

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

А вообще корни проблемы растут от overcommit-а. Вот это тоже глупость та ещё. Кому только в голову пришла. Память нужно выделять сразу. Сколько запросили - столько выделил и зарезервировал. Или NULL вернул. И точка.

Управление памятью и так кромешный ад, а такие хотелки просто нереалистичны.
Будет как в старые добрые времена: программы начнут городить свои велосипедные файлы подкачки, чтобы выжить в этих стальных джунглях.

Это просто перекладывание ответственности.

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

Можно купить яблобук и поставить на него настоящую операционную систему.

Типа как в том анекдоте про обман Таксиста ?

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

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

Какие старые добрые времена?

Вот в настоящем:

Во Haiku нет overcommit.

В Windows нет overcommit.

В NetBSD нет overcommit.

Во FreeBSD и MacOS вроде есть overcommit, но выключен по умолчанию…

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

Я уже приводил пример, что вон проходит десять лет и ноутбук лишается поддержки Apple.

А так вон линуксоиды могут со свалки взять и пользоваться.

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

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

Это с overcommit оно кромешный ад, а без него всё просто: не хватило памяти – не открылось окно, не запустилась программа и всё. Уже запущенные программы работают и ничего не убивается. В Haiku OOM killer отсутствует в принципе т.к. не нужен.

Реализуется это без проблем если использовать RAII и обработку исключений. Программисты на Си должны страдать.

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

И что нет проблем с АКБ у таких ноутов ?

P.S. Думал что М1 это что то новое …

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

Если нет понимания, как должны проходить границы зон ответственности, чтобы можно было избежать протечки абстракций и абьюза системных механизмов, то остаётся только про C++ и рассуждать.

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

Вот только архитектор системы должен смотреть не изнутри приложения, а сверху на всю систему. А то сам окажется винтиком в ней.

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

В NetBSD нет overcommit.

С опеннета принёс?

https://www.netbsd.org/docs/kernel/uvm.html#uvm-out-of-memory

How does UVM handle running out of memory?

UVM uses lazy allocation. This means programs can overallocate virtual memory. When UVM detects an out of VM completely condition and a lazy allocated bit of memory is accessed, the offending process will be KILLed and the system will continue. There is also a small buffer of reserve pages only for use by the paging system, which allows the pagedaemon to run comfortably when there is otherwise no free ram. Most of this work was done by Chuck Silvers.

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

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

Это скорее повреждение мозга Сишным императивным мышлением и закатом солнца вручную. В C++ можно мыслить декларативно в понятиях структур данных и владения. Структуры данных в памяти – это как база данных, а исполняемый код к ним прилагается, его можно в любой момент прибить сохраняя консистентность структур данных. Когда код обработки запроса базы данных падает, ничего страшного не происходит, вот и со структурами данных в памяти на C++/Oberon/Go тоже самое.

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

https://www.netbsd.org/docs/kernel/uvm.html#uvm-out-of-memory

А как malloc, new и прочие работают в NetBSD?

В Windows есть https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc который при flAllocationType MEM_RESERVE может просто резервировать память. Но это системное API, это нужно делать специально. А по умолчанию malloc, new и подобные функции делают MEM_COMMIT.

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

Я тебе уже говорил раньше, ты пытаешься решать несуществующую задачу.

В ситуации нехватки памяти кто-то должен зафейлиться всё равно. А кто это будет — должна решать не воля случая, а верхнеуровневый арбитр, проинструктированный админом локалхоста. Он точно знает, какая задача отмечена более или менее ценной для пользователя. А не тупой рандом.

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

у меня интернеты через него были несколько лет

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

А как malloc, new и прочие работают в NetBSD?

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

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

В ситуации нехватки памяти кто-то должен зафейлиться всё равно.

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

а верхнеуровневый арбитр

Без сильного ИИ нереализуемо в принципе.

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

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

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

На ком память закончилась, тот и зафейлился.

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

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

Сильный ИИ сидит перед монитором.

Поэтому пользователь сам может завершить приложения если памяти не хватает без всяких убогих рандомных OOM-killer’ов.

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

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

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

В Федоре если не ошибаюсь уже сделали.

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

пользователь сам

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

рандомных OOM-killer’ов.

С больной головы на здоровую? Ни разу не видел рандома при работе OOM-killer-а, а вот в вашей любимой Шин95 — насмотрелся еще в прошлом веке.

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

Да, всё так и должно быть.

Вопросов, замечаний больше не имею.

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

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

Тут кстати файл подкачки и поможет. Если Гном просто выделил себе про запас, но не использует сейчас, то ядро это задетектит и просто перенесёт эту память в подкачку.(Даже не будет писать на SSD если память не трогалась). А активный набор который использует приложение всё также будет в RAM.

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

Хотя нет. Имею.

GUI-приложение хотело сохранить данные в файл, но на этапе подготовки к сериализации получило out of memory exception.

Действия приложения?

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

Тут кстати файл подкачки и поможет. Если Гном просто выделил себе про запас, но не использует сейчас, то ядро это задетектит и просто перенесёт эту память в подкачку.(Даже не будет писать на SSD если память не трогалась). А активный набор который использует приложение всё также будет в RAM.

Смысл этого действия в чем?

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

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