#linux - это embedded. #scheduler

Что такое embedded? Это когда вам дают какой-то заранее собранный и преднастроенный программно-аппаратный комплекс, который выполняет какую-то функцию, и вы его используете, как черный ящик.

Я хочу аргументировать, что все известные и выстрелившие использования ядра Linux - это embedded.

КМК, единственное сомнение в этом утверждении может вызвать использование Linux в датацентрах. Но, если посмотреть на это под правильным углом, то линукс в датацентрах - это тоже глубокий embedded, потому что:

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

* вендоры предоставляют образа для запуска Linux в своих облаках

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

Можно было бы привести в пример Android, как пример "открытой" системы, но и там:

* Прошивку вылизывает вендор

* Приложения сильно ограничены VM sandbox, которая делает много магии, чтобы они все вместе работали "плавно"

Поэтому "Linux на десктопе" - это оксюморон, он последние лет 10 точится совсем в другом напрявлении. Linux - давно не "OS общего назначения".

Правда, тут стоит отметить еще следующие факты:

* macOS - это что-то типа Android по своим свойствам, потому что Apple тюнит свою OS под ограниченный набор устройств, и очень сильно ограничивает приложения

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

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

Удивления это не вызывает, системы становятся все сложнее, и, кажется, вот эта стадия "пуско-наладки" тоже будет все сложнее и сложнее, и без специально обученных людей будет не обойтись.

Ненавижу #cmake.

Это самая худшая система сборки ever.

* Она не умеет в кросс-компиляцию, писал об этом неоднократно #cross

* Фактически, cmake - это интерпретируемый язык с смесью синтаксиса qbasic и cobol, на которой можно как-то написать кривую и косую систему сборки, потому что язык turing complete.

Сложность скриптов на cmake ограничивается только всратостью самого языка, и ничем более.

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

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

https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, вот она

Ее поведение можно переопределить 10 разными способами, например

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#variable:CMAKE_SYSTEM_PREFIX_PATH

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_IGNORE_PATH.html#variable:CMAKE_SYSTEM_IGNORE_PATH

find_package() в cmake содержит в себе 10 настроек для этих 10 переменных, https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package - искать по "NO_CMAKE_".

Каждая из которых каким-то нетривиально-всратым образом меняет семантику find_package.

Долбоебы из QT решили, что и этого им мало:

* они переопределили поведение по умолчанию, чтобы либы из QT не искались в CMAKE_PREFIX_PATH

* Они завели себе переменную QT_ADDITIONAL_PACKAGES_PREFIX_PATH, на замену CMAKE_PREFIX_PATH

* Они завели себе переменную, выключенную по умолчанию, которая возвращает поведение к "нормальному"(насколько это возможно в cmake вообще) - QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES

Я НЕНАВИЖУ, когда у программистов заканчивается работа, и они начинают маяться хуйтой.

———
Хозяйке на заметку.

Я потихоньку профилирую свой Linux, ищу, что и где плохо лежит происходит не так, как мне нравится, и починяю.

Вот, возможно, пригодится.

#foot по умолчанию запускает ncpu threads для параллельного рендеринга.

Но мы-то знаем, что дисперсия времен ответов от большого числа источников(иными словами, барьер на синхронизацию событий "мы все сделали!") штука опасная, и может быть большой. Например, потому что #scheduler в Linux - говно. Тем более, если запускать по 16 render threads. Ну и памяти под стеки они жрут прилично.

TL;DR - если убрать вообще все worker threads, и оставить только main, скорость рендеринга не меняется никак(проверяем с помощью cat на большой файл, с ansi escape codes)

Тащемта, понятно, откуда там взялся многопоток - автор foot, очевидно, испытывает комплекс перед #alacritty, и ему нужно были эти эфемерные 10% ради собственного спокойствия.

А вам я рекомендую ставить workers=0 в конфиге, работает так же, памяти жрет меньше.

Много раз обещал написать, зачем свой дистрибутив Linux, и почему он так устроен. #stal/IX #gold

Часть первая, "зачем".

Мне в современных OS очень много чего не нравится.

* Мне не нравится шедулер Linux. #scheduler

* Мне не нравится закрытые части в macos, ее политика по отношению к приложениям, и, особенно, к инструментам разработчика(профилирование, отладка - все это перестает работать "из коробки")

* Мне, для примера, очень не нравится, что в Unix orphane process прибивается к init'у, я хочу, чтобы все мои процессозапускалки не делали double fork, чтобы видеть completely supervised tree

* Мне не нравится сложность, которую RedHat привносит в Linux, например, systemd - это универсальный(и очень плохой!) запускатор динамического графа задач, система управления загрузкой там вообще сбоку. (правильно, кстати, сделано в macos, там отдельно начальный загрузчик, отдельно socket activation, и так далее) PipeWire - универсальный обработчик графа мультимедия потоков, и нахер он никому не нужен в таком качестве, все вменяемые(да-да, "ни один истинный шотландец") плееры берут дубовый ffmpeg, без вот этой вот всратой динамики и резолве зависимостей плагинов в runtime.

* Мне не нравится наслоение говен на говны в современных LFS/LSB дистрибутивах. Ах, динамическая линковка ведет к dll hell, ну, мы ее оставим, но приделаем ostree и контейнеры для деплоя приложений. Знаете, это решение из серии "сохранить лицо", а не перепридумать, как было бы правильно сделать с самого начала.

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

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

Написать свою OS? Меня этим троллят примерно раз в месяц, и, кстати, я бы запилил неплохую OS(как-нить надо написать, как бы она была устроена). Проблема только в том, что современное(на данный момент времени) графическое приложение я там запущу лет через 15, и то, если сильно не объебусь с архитектурой и инструментами.

Я себе это представляю довольно точно, можно просто посмотреть на динамику развития Linux, и экстраполировать ее исходя из:

* взять нормальный язык, чтобы писать раз в 10 быстрее, чем это делают разрабы Linux

* взяв нормальные архитектурные принципы построения ядра

https://www.opennet.ru/opennews/art.shtml?num=57260 - цифры про размер ядра.

Я так примерно понимаю, что Linux стало норм где-то в районе 2.6, 5 - 10 MLOC. Если взять нормальный язык, надо настругать где-то 0.5 - 1 MLOC.

В общем-то, все предсказуемо, и очень грустно.

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

Например, запилив демон, который прибивает все прибившиеся к init orphane process, постепенно и инкрементально.

Например, отказавшись от динамической линковки и от dll hell, как КЛАССА проблем.

Как это запилить в той же Fedora - это убиться же можно.

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

Из всего вышесказанного следует:

* совершенно бессмысленно меня спрашивать, "почему не systemd"

* "почему не ostree"

* "почему ...

Я пытаюсь как-то по другому решить известные мне проблемы, это исследовательский hobby дистрибутив, а не конкурент для RHEL на его поле.

Если меня устраивает systemd и dll hell, я возьму Fedora, и не буду париться.

Мне же интересно "а как, вообще, можно иначе".

#gold

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

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

Я добавил в систему #ananicy, чтобы можно было регулировать всякими интересными настройками для выполняющихся программ - rt prio, nice, etc.

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

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

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

Задача эта часто противоречит задаче "выполнить заданный код наиболее быстро в среднем"(собственно, это то, что хотят от OS жадные капиталисты в датацентре), и поэтому RTOS и просто OS - это, обычно, разные продукты.

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

Решается эта задача, если очень грубо:

* Очень простой шедулер. У каждого процесса/треда есть свой приоритет, если в очереди на выполнение есть процесс с бОльшим приоритетом, чем тот, что сейчас выполняется, то выполняемый процесс вытесняется в пользу более приоритетного. В целом, этого уже почти достаточно, чтобы код работал предсказуемо.

* Некоторое расширение модели выше - когда OS делает асинхронную задачу в рамках ядра для какого-то процесса, она должна эту задачу во все свои внутренние очереди тоже класть с приоритетом процесса, которой ее заспаунил. Короче, таска в io queue должна иметь приоритет своего процесса, чтобы io тоже был приоритезированным.

* Priority inversion, priority inheritance. Тут все просто - если процесс с бОльшим приоритетом залочился на mutex, которым владеет процесс с меньшим приоритетом, то надо на время забустить приоритет этого процесса до максимального значения из приоритетов всех процессов, кто хочет этот mutex. Вроде, примерно понятно, зачем это надо, не буду вдаваться в подробности.

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

Короче говоря, я разметил все процессы в системе, имея вот это свое понимание, что такое RTOS, и как оно должно работать:

* Композитор имеет класс FIFO, потому что композитор - эта такая штука, которая ничего сама не делает, и только диспатчит сообщения через pipe. Я, опять, долго объяснять не буду, просто подумайте, нужно ли вообще такому процессу иметь возможность быть rescheduled посреди акта своей работы. Мой ответ - нет, не может, это приведет к увеличению latency всей системы, без влияния на throughput.

* По тем же причинам я поставил FIFO для звукового демона, и для dbus брокера.

so long, so good.

Так же я выставил RR класс для web process и gui process браузера epiphany.

* FIFO - это очень простая и понятная штука, тред с FIFO классом выполняется строго по правилам, которые я описал выше.

* RR - это какое-то не до конца мне понятное изобретение в теме, потому что RR класс говорит нам, что RT задачи с одинаковым приоритетом будут обрабатываться через round robin subscheduler. Я думаю, что вы уже поняли, что я считаю такую трактовку RT несколько легкомысленной, потому что что это за херня - задачи с одинаковым приоритетом в RT системе?

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

(продолжение)

И, знаете, эта система приоритетов работала настолько хорошо, что я уже было собрался писать победный пост, как я загнул #scheduler, и у меня все работает плавнее, чем в macos. Кстати, похвастаюсь, что, без нагрузки это УЖЕ так, помогли все мои облизывания и политик шедулинга, и тюнинг аллокатора, и так далее.

Но, конечно, Linux и тут себя показал в своей красе, и это какой-то леденящий душу пиздец.

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

- я запускал сборку чего-то тяжелого, оно насыщало все CPU.

- в этот момент заходил на сайт с зависшим JS, процесс браузера(который, напомню, RR) начинал жрать 100% CPU.

В этот момент начинал срабатывать какой-то сраный код в ядре, который позволял загруженному на 100% RR треду периодически прерывать выполнение FIFO треда от композитора. Даже на самом деле слегка не так, система ограничила сверху время для FIFO + RR задач в какой-то процент от CPU, что привело к тому, что FIFO задача иногда reschedule посредине своей работы.

В этот момент появлялась какая-та всратая фраза в dmesg, про включение тротлинга, погуглив которую я и узнал, что это just as planned. Ну, то есть, долбоебы-разработчики позаботились о том, чтобы FIFO тред не мог съесть весь CPU, несмотря на то, что я попросил именно это.

Ссылку не дам, потому что затерялась, а восстанавливать весь setup сейчас лениво. Самое близкое, что нашел - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling

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

Если вы внимательно прочли мое описание RTOS, то должны согласиться, что такое поведение неприемлемо для RT системы, и, если бы система вела так, как заявлено, то такого эффекта бы не возникало.

Разработчики этой дичи спецкурс моему преподу, конечно, завалили бы.

Короче, TL;DR - выставил я nice для браузера вместо RR, оно, конечно, лучше, чем без nice, но даже и рядом не стояло с правильным, нужным мне, поведением.

#scheduler я пока не победил, но все еще не отчаиваюсь!

https://www.phoronix.com/news/Google-Ghost-Linux-Scheduling

Про user space #scheduler от FB я уже как-то писал, но вот то, что и Гугл делает что-то подобное, я не знал.

С точки зрения API это выглядит очень правильно - агент имеет полное состояние CPU в данный момент(инкрементальными апдейтами), и может отдавать команды вида "запусти тред Х на CPU Y".

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

Почему я думаю, что справлюсь лучше?

Потому что политика вида "любой тред браузера имеет право растолкать всех остальных, но не больше 5 секунд(после чего он признается зависшим javascript)" - это хак, который никогда не будет реализован в ядре, а я смогу сделать.

Новости из мира Linux:

https://www.phoronix.com/news/Bcachefs-Merged-Linux-6.7 #bcachefs

bcachefs вот так взяли, и смержили в 6.7. Видимо, #Kent нашел правильное место, куда надо лизнуть, потому что иначе такой прогресс сложно объяснить.

Вышло ядро 6.6 - https://www.opennet.ru/opennews/art.shtml?num=60016 #scheduler

В нем, из прямо очень интересного, - совсем новый шедулер процессов. На этот раз коллеги, прежде чем велосипедить почем зря, прочли какую-то статью, из академии - https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=805acf7726282721504c8f00575d91ebfd750564 Я эту статью пытался прочесть уже раза 3, но где-то посередине текста мне становится очень скучно, и я откладывал ее на полочку. Радует, что там есть какая-то понятная модель, и, какой-никакой, но матан!

#scheduler

Расширяемый шедулер едет в ядро - https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler https://lwn.net/Articles/978007/
https://www.opennet.ru/opennews/art.shtml?num=61354

День, когда у меня перестанет тормозить браузер, все ближе и ближе, what a day to be alive!