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

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

Это заблуждение. Память должна свопиться всегда.

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

Да хоть 60 ТБ.

Зачем тогда дёргать диск путем своппинга, если СВОБОДНОЙ памяти дохрена?

Свободной памяти много не бывает. Дисковые кеши всё забивают моментально.

Преждевременный своппинг - это преждевременная нагрузка на диск. Это даже хуже оверкоммита: от оверкоммита диск не страдает.

Что у тебя там за страдающие диски? Прекращай этот ненужный гуманизм. Аппаратура должна работать.

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

Оставлять несколько десятков памяти в резерве для избранных приложений (графический интерфейс, эмулятор терминала, bash, ps, kill и тд). Чтобы в любой ситуации определённый функционал оставался работоспособным.

После определённой границы (например 90% памяти+свопа занято) вводить экспоненциально растущие искусственные задержки, чтобы до 100% никогда дело и не дошло.

Это все должны делать костыли или ядро? Ты ж вроде был против костылей.

В чём тут костыли? Выделять некоторое количество резервной памяти для обработчика ошибок это нормальная практика безопасного программирования. Ничего страшного в этом нет, в 99% случаев эта память (при правильно работающем свопе) уйдёт на диск через некоторое время после запуска программы и просто будет отнимать несколько килобайт свопа, это не беда.

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

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

это не то место кончилось которое общее, а кластеры

Ну я понимаю, что какие-то метаданные исчерпались, мне в ошибке и в df -h написало, что диск заполнен, что там технически кончилось, без разницы. Суть в том, что побочных тормозов в системе не было. Ну правда флешки у меня USB-3, медленных уже сто лет не использовал.

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

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

Потому что юзерспейс не ядро. Писать таким же образом юзерспейс можно, но кто будет платить за удовольствие? Ты готов к тому, чтобы КАЖДАЯ программа писалась и отлаживалась в 3 раза дольше?

Вопрос в том, ради чего это должно делаться. Что ты хочешь добиться не абстрактным «это правильно, а это неправильно», а конкретно.

Разница в том, что киллера не должно быть вообще, как концепции.

Кому не должно? Вот у меня сервак стоит месяцами работает без обслуживания админом. Кому там что «не должно», там всё автоматизировно. И если протек какой-нибудь питоноскрипт в цикле, то он должен умереть, в журнал должна быть направлена запись, а остальные части продолжили бы работу. А не вставало всё колом и не ждало админа.

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

Ради бога, за твои деньги любой каприз. Нужно? Отлично. Цена вопроса? Я не готов потратить всю жизнь на решение несуществующих проблем, но если заказчик платит — то можно и поработать.

раз понимания проблемы нет

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

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

Баг формулируется в формате «Для решения поставленной задачи поведение должно быть вот таким, а в программа ведет себя иначе». Начинать нужно с задачи. Я говорю о реальной практической задаче, а не чувстве прекрасного. За чувство прекрасного в нашей сфере не платят деньги.

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

Это заблуждение. Память должна свопиться всегда.

Чего?

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

Вот у меня сервак стоит месяцами работает без обслуживания админом.

Речь про десктоп, а не сервер. Для сервера совершенно другие требования к работе ПО. За десктопом всегда сидит пользователь, который запускает и завершает программы по мере надобности. Самодеятельности от системы не требуется.

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

Речь про десктоп, а не сервер. Для сервера совершенно другие требования к работе ПО. За десктопом всегда сидит пользователь, который запускает и завершает программы по мере надобности. Самодеятельности от системы не требуется.

Десктоп точно так же гоняет кучу задач, не нуждающийся в постоянном ручном мониторинге.

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

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

Десктоп точно так же гоняет кучу задач, не нуждающийся в постоянном ручном мониторинге.

Если только какая-нибудь телеметрия и Кортана в Windows и прочее не нужно. Но оно как раз прекрасно работает без оверкоммита.

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

сетевые сервисы крутятся

Какие? Что это делает на десктопе, если есть отдельный сервер?

отлаживаемые сайты

Для этого есть php artisan serve, python manage.py runserver, docker run или на каком там фреймворке оно написано. Запускается и останавливается руками из консоли, прописывать в сервисы смысла не вижу.

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

Что это делает на десктопе, если есть отдельный сервер?

У меня компьютер для работы, а не чтобы на нём фапать на концептуальную завершенность «десктопа».

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

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

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

УМВР

используя линуксовые устревшие технологии ffmpeg с GPL на С

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

и никто не сделает - шах и мат фетишистам

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

используя линуксовые устревшие технологии ffmpeg с GPL на С

Ffmpeg к Линуксу не имеет никакого отношения, оно нативно работает в *BSD, Haiku, Windows, да почти везде.

и никто не сделает - шах и мат фетишистам

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

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

Ffmpeg к Линуксу не имеет никакого отношения, оно нативно работает в *BSD, Haiku, Windows, да почти везде

сказки тут не надо рассказывать, она написана людьми из линуксовой тусовки под GPL и портирована на любой утюг потому что это мидлваре на С

Планирую как-нибудь этим заняться.

что ещё делать если только планировать и получается

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

Так есть же copy on write. Допустим процесс форкнулся, памяти для этого хватило. Потом начал писать пошареную между двумя процессами область памяти, ядро начало искать страницы памяти, свободных страниц памяти нет. Какой тут null? Кому его возвращать? А copy on write между тем вполне годная фича с точки зрения системной производительности. Если этот механизм убрать, то fork() начнёт тормозить

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

Просто резервируй память при cow. Если начнёт писать - резерв есть. Не начнёт - и ладно. Резерв, естественно, с учётом дискового свопа, т.е. физическую память не отнимает и у дискового свопа отнимает только «виртуальный» размер, который не будет использоваться.

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

Зачем если есть Clang, который прекрасно работает?

С учётом того, что libstdc++ поддерживает Clang, то наверное можно пользоваться и Clang

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

Никогда этого не понимал. Почему тогда Clang самый отсталый компилятор С++ по части поддержки стандарта?(особенно Apple Clang) Если в исходниках проще разобраться + количество людей работающих над Clang/LLVM больше чем над любым другим компилятором.

Одних компаний только Google, Apple, Sony, Nintendo, Intel(перешли с собственного на clang), Embarcadero(тоже перешли на clang вместо своего старого). Даже Microsoft комитит:

https://github.com/llvm/llvm-project/commits?author=StephanTLavavej

https://github.com/llvm/llvm-project/commits?author=CaseyCarter

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

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

Вот только oom killer грохнет тебе не какой-нибудь потёкший питоновский скрипт-демон, а процесс базы данных.

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

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

Из того же исходят, рассуждая про ПО, наш случай, например, верует в идеал десктопа, который был якобы достигнут в BeOS, и никак не поймет, почему его Haiku - неконкурентоспособная игрушка, другие же боготворят ущербные идеи унихов, и единственная мыслимая для них причина закапывания униха/гайку - жидомассонский заговор.

Увы, к появлению таких особей и приводит всеобщая шизофрения общества и деконструкция не только межчеловеческих связей, но самого человека (idpol, например), которую мы наблюдаем на срападе (и у определённых лиц на Востоке).

Корни, как всегда, в жидовском талмудыческом анти-мышлении.

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

Intel(перешли с собственного на clang),

Когда это Штеуд перешёл на шланг? То что они что-то туда коммитят ничего не подтверждает, так-то они и в гцц коммитят.
Свой ицц они не забросят, т.к. топопвые фичи и оптимизации идут в первую очередь туда, за что они и берут деньги.

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

Так это набор компиляторов и icc туда входит. icc это «classic compiler», есть ещё icpc, который «data parallel». Где-то так, насколько помню.

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

Тогда кратно вырастут требования по памяти. Есть у нас какой нить postgresql с жирной базой, вот у него там на каждый коннект форк идёт. При текущей логике сервак может обслуживать 200 одновременных коннектов, а если убрать cow, ну т.е. включить overcommit для него, то будет держать только 30

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

Не к памяти, а к свопу.

Ну и ты померь сначала. Ерунда там будет.

Ну и через mprotect вроде можно сделать память READONLY.

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

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

А ты единолично владеешь Haiku? Или у вас там принято класть на мнение и пожелание юзеров?

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

Про cow - это шах и мат. Ты запусти какой-нибудь простейший баш скрипт (ну хоть тот же git status) под стрейсом и посмотри, сколько он процессов форкает.

По твой логике надо на каждый форк делать полную копию всех private mappings (потому что в общем случае ядро не знает, будут ли они перезаписываться). А это все, что аллоцировано malloc. И даже если за ним идет exec для запуска дочернего процесса (наверное процентов 80 всех форков).

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

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

Я где-то за месяц запилил поддержку RISC-V для Haiku включая GUI.

Сходил по ссылке, почитал, даже зарегистрировался чтобы написать: Отличная работа!

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

По твой логике надо на каждый форк делать полную копию всех private mappings (потому что в общем случае ядро не знает, будут ли они перезаписываться).

Ещё один прозрел.

fork() не нужен, есть posix_spawn().

И даже если за ним идет exec для запуска дочернего процесса (наверное процентов 80 всех форков).

Можно обработать особым случаем.

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

наличие драйверов для видеокарт это у тебя за устаревшую технологию считается?

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

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

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

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

oom killer грохнет тебе не какой-нибудь потёкший питоновский скрипт-демон, а процесс базы данных

адекватный админ выставляет отрицательный oom_score_adj для СУБД, поэтому киллер не грохнет СУБД

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

Память должна свопиться всегда

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

Свободной памяти много не бывает

Бывает, и были такие лоровцы. Что-то типа 60 гиг всего, 12 занято вместе с кэшами, и десятки гиг. СВОБОДНОЙ. Нахрена в таком случае свопить, если свободная не собирается заканчиваться?

Дисковые кеши всё забивают моментально.

Нихрена подобного. Моментально могут сгенерироваться сотни гигабайт кэша для текущей работы. Для забива десятков гиг могут понадобиться дни и недели в зависимости от нагрузки.

Аппаратура должна работать

Да, если это реальные задачи, а не убийство ресурсов бесполезной работой.

Прекращай этот ненужный гуманизм

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

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

сотни гигабайт кэша

ошибочка, сотни МЕГАБАЙТ.

anonymous
()

Феерическая расстановка точек над 12309

Вообще сто лет назад натыкался не то в рассылке, не то в багзилле ядра на мнение о том, что наша хвалёная идея с тюнингом vm.dirty (неважно, bytes или ratio, суть-то одна и та же) — это тоже не самая правильная затея, потому как величина, ликвидирующая затупы для внешних накопителей, для внутренних будет слишком мала. Допустим, когда у нас SATA и USB 3.1 — это не так критично, но вот на сцену выходит NVMe весь в белом.
Решение у проблемы одно: отдельные лимиты для внешних носителей, но этим, насколько я понимаю, так никто и не озаботился, потому что проблема и плавающая, и сугубо десктопная.
Я лично дякую боже за то, что ни разу не ловил серьёзных фризов на этой почве, хотя каноничную историю, когда скорость копирования на флешку падает с двух гигабайт в секунду до сотни килобайт и так тошнит добрый час, видел не раз и не два.
И да, earlyoom на ноуте держу. Потому что не занимаюсь на нём mission-critical задачами, и в случае кирдыка мне важнее сохранить отзывчивость, нежели дожидаться, пока хром отдаст память. Но я не спорю с тем, что в качестве дефолта это нужно, мягко говоря, не всем.

dogbert ★★★★★
()
Ответ на: Феерическая расстановка точек над 12309 от dogbert

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

А также винчестеры с черепичной записью…

А NVMe накопители напрямую не мапятся в память?

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

А также винчестеры с черепичной записью…

О, кстати да. Но у меня боль вообще была связана со встроенным кардридером, который какая-то добрая душа в самсунге подключила по шине USB 2. Ну то есть там вообще какие-то смехотворные значения надо было выставлять, чтобы он не захлёбывался — а ведь тем временем внутри уже стоял SSD.

А NVMe накопители напрямую не мапятся в память?

Да, пардон, там же DMA. Я правда не понял, что мне как юзеру это даёт, ну да ладно.

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

Угу. Я помню каким сюрпризом для меня оказалось что OOM может грохнуть работающий Oracle, потому что какая-то мелочь пузатая запустилась.

Насчет числодробилки и трех суток работы - это проще решается. Если ты пишешь такие, то потрать лишний день на дописывание сброса на диск промежуточных вычислений и на подъем их при старте.

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

Я верю что наконец-то скоро настанет эра тонких, легких, бесшумных, мощных и энергоэффективных ноутбуков!

Вычеркни из этого списка два любых пункта ))

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

Ты монстр!

Haiku - по фану или какие-то далеко идущие планы есть?

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

Именно. Хром, к примеру, совершенно не стесняется:

36,6g 452,2m 103,6m S 1,0 1,4 17:31.02 /opt/google/chrome/chrome

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


Когда кончится хайп вокруг m1?


Когда выйдет m2 :)

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

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

не должна, вернее, нужна только поддержка dx11. а это видеокарты 2009г. вулкан на мобильниках работает, где видеокарты гораздо более кастрированные по фичам

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

извиняюсь за ошибку. Однако не dx11 а OpenGL ES 3.1 или OpenGL 4.x и выше. directx тут вообще не причем. Но для старых видиокарт сейчас уже делать ни чего не будут, если их не поддерживают

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

Так тоже самое и смартфонов касается — на старых не работает и не будет.

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

https://www.ixbt.com/news/2016/08/27/soc-snapdragon-800-801-android-7-0-qualcomm.html

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.