Как натянуть сову на глобус семантику Rust на C++:
https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub

Спойлер: увы.

RedHat планомерно сворачивает "бесплатный RedHat Linux", во всех его проявлениях. Интересно, ждет ли ее судьба ELK && MongoDB? https://www.opennet.ru/opennews/art.shtml?num=54219

Microsoft колбасит .NET:
https://www.opennet.ru/opennews/art.shtml?num=56027
https://www.opennet.ru/opennews/art.shtml?num=56020

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

———
Я как-то обещал написать про то, как #eBPF && #io_uring поменяют Linux, но так и не написал. Давайте я совсем коротко обозначу свою мысль, а раскрою ее позже.

Благодаря тому, что syscall станут бесплатными(io_uring), и станет возможным безопасно выполнять пользовательский код в контексте ядра(eBPF), ядро станет мигрировать в область микроядра - сервисы в пространстве (kernel-user)space(кто сказал "Microsoft Singularity?!" - https://ru.wikipedia.org/wiki/Microsoft_Singularity), c реализацией ядерной функциональности.

Это не просто спекуляция - сеть уже едет вовсю в (kernel-user)space, а вот теперь и шедулер: https://lwn.net/ml/linux-kernel/[email protected]/ (патчи от нашего бывшего коллеги!) #sched

Про scheduler в Linux. #sched #gold

Я знал, что шедулер в Linux хуйовый(мат intended), но что на десктопе все сломано настолько, я не понимал. У меня во время компиляции тормозит браузер(любой). И я ничего не смог с этим сделать.

Вот команда запуска компиляции(IO я не трогаю, все в памяти):

chrt --idle 0 cpulimit -l 1400 -i nice -n 20 ./mix realm upgrade

Я ограничиваю число ядер для компиляции(14 из 16), я выставляю nice, я помечаю треды на idle, чтобы они вытеснялись любым более приоритетным кодом.

Команда запуска браузера примерно такая же, только - заменяем на +, —idle на —rr, etc. Команда запуска композитора тоже(все, что затрагивает user facing процессы, запущено с повышенными scheduling privileges).

И это не помогает. На минуточку, я для браузера оставил полноценное ядро(2 гипертреда), у меня число процессов в очереди на выполнение < CPU CORES, и все равно, шедулер как-то умудряется просрать(сука! ненавижу!) все полимеры. Почему так? Я вам расскажу!

Первое соображение - про процессы разработки.

Я уже много раз рассказывал, ядро Linux пишут красноглазые хакеры. Без нормального процесса разработки, тикетов, тестов, etc. Код соответствующего качества. Как нормальный разраб бы оформил шедулер? А вот так:

IScheduler* scheduler = new WorkStealingScheduler(
   some kernel interfaces)...
...
auto job = sheduler->nextWorkItem();

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

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

Есть, типа, описание, как должен работать шедулер:

https://en.wikipedia.org/wiki/Completely_Fair_Scheduler
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Господа, да если бы он работал по этому алгоритму, было бы счастье! Этот алгоритм by design не допускает лаги, когда у меня число выполняющихся процессов < CPU CORES! Так он уже давно по нему не работает.

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

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

Кстати, Con Kolivas отказался от идеи запилить нормальный scheduler для Linux. https://www.phoronix.com/scan.php?page=news_item&px=Con-Kolivas-EOL-MuQSS-CK Я бы, на его месте, послал всю эту пиздобратию еще раньше, когда Ingo Molnar, вместо того, чтобы признать, что Con лучше справился с работой, просто потырил его идеи в свою реализацию.

Второе соображение - пошедулить браузер существенно сложнее, чем пошедулить Apache. Прямо на порядок сложнее. Когда ты шедулишь Apache, тебе пофиг, что ты там где-то просрал квант времени. Когда ты шедулишь браузер, тебе надо выдавать стабильный RPS в 120, и просер одного кванта времени заметен. Тебе нужно реализовывать сложные алгоритмы, что, если ты отпустил lock, то твой квант времени доедает тот, кто этот lock получит(то же самое про запись в pipe). Почему это важно? Потому что тебе нужно, чтобы композитор моментально начал свою работу после того, как ты ему просигнализировал, что твой буфер с окном готов.

Под что тюнят облачные корпорации Linux scheduler? Вопрос риторический.

Итак.

* Шедулер в Linux сломан давно и навсегда(для десктопа, да и для серверов, если вы не большая корпорация со штатом крутильщиков ручек)
* Лучше всего(для десктопа) он работал в 2006 - 2008 году, пока его разработчики тюнили его под свои же workstation. Вот тогда реально все было плавненько.
* Чего там ищет Valve для гейминга в Linux - я не понимаю. https://www.opennet.ru/opennews/art.shtml?num=56390

https://www.phoronix.com/scan.php?page=news_item&px=Sway-1.7-rc1

Вышел новый rc Sway. Самое заметное нововведение - больше не нужно указывать для ./configure —my-next-gpu-wont-be-nvidia

По нынешним меркам хорошо, что не заставили извиняться(только вот кого, Sway или Nvidia?)

А чо, у меня вот шаблон для gnu-тых проектов называется autohell.sh, чего уж тут.

———
https://github.com/endrazine/wcc

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

Прекрасная, прекрасная вещь. Позволяет превратить .exe в .so, .so в .o, ну а то, что можно с помощью lua превратить любой .exe в shell с возможностью вызова любой функции - я уж вообще молчу.

Полагаю, мне это будет полезно, когда я захочу статически слинковаться с NVidia libGL.so

———
https://systemfolder.wordpress.com/2015/01/17/about-box/

А вот коллекция splash screen всякого старого софта. Prehistoric porn, все, как мы любим.

———
В свете поста про scheduler #sched нам пишут телезрители - оказывается, большие компании проблему понимают, и пытаются ее решить. Шедулер в user space - это прекрасно, у меня просто полно идей, как можно сделать хорошо.

https://lwn.net/Articles/869433/
https://dl.acm.org/doi/10.1145/3477132.3483542

———
Ну и выжимка текста про "починку" одного бага в шедулере(ссылка в прошлом сообщении, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/):

"The original rationale for the behaviour was to maximise cache reuse – but for some applications waiting in the runqueue for the sake of better cache reuse does not pay off. The bug was triggered by a widely used commercial database configured with 64 worker threads.

To fix this bug, we alter the code that is executed when a thread wakes up. We wake up the thread on the local core – i.e. the core where the thread was scheduled last – if it is idle; otherwise if there are idle cores in the system, we wake up the thread on the core that has been idle for the longest amount of time. If there are no idle cores, we fall back to the original algorithm to find the core where the thread will wake up."

Вдумчивый читатель обнаружит, что починка добавляет еще 1 баг. Надо не longest amount, а shortest amount, потому что иначе возможна ситуация, когда будет 10 медленных ядер(напомним про тротлинг CPU) вместо 5 быстрых. Впрочем, возможно, нужно именно longest amount, просто я не понимаю, почему.

https://www.youtube.com/watch?time_continue=203&v=Zh3Yz3PiXZw&feature=emb_logo

Прекрасный видос, я, как обычно прослоупочил.

———
https://twitter.com/proffeynman/status/1038833676962869249?lang=en

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

———
Факир был пьян, фокус не удался.

yash отлично справляется с configure скриптами, но валится на каком-то bash-изме в libtool.

eval 'f ( X "" )' - что это? по мне так yash прав, что missing ), потому что f( - начало определения функции.

Видимо, автор dash это закостылял, потому что dash какое-то время был дефолтным shell в ubuntu(про сейчас не знаю). Без этого костыля #autohell проекты не собираются.

На закуску - автор yash упоролся, и переписывает его на Rust. https://github.com/magicant/yash-rs/issues

Вот зачем, зачем переписывать то, что уже написано и работает? Я там понимаю, если бы он фич хотел досыпать, но он же опять пишет posix shell.

———
https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/

range-based for-loop аккуратно обошли стороной. C++ doomed.

———
Intel отчаялась победить шедулер #sched в Linux, и теперь CPU просто сам говорит - "пошедули чего-нить на меня", или "я перегрет" https://www.tomshardware.com/news/intel-alder-lake-thread-director-support-coming-to-linux

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

https://www.phoronix.com/news/sched_ext-Ahead-Of-Linux-6.12

Linus жмется, и не пускает #sched_ext в ядро.

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

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

А я-то, было, уже собрал https://github.com/sched-ext/scx, и, потирая ручки, ждал, когда же уже

"The following video is the scx_rustland scheduler which makes most scheduling decisions in userspace Rust code showing better FPS in terraria while kernel is being compiled. This doesn't mean that scx_rustland is a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios"

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

Мама дорогая, сколько они там нахуевертили за 30 лет существования этой технологии, уму непостижимо.

Но, самое главное, они наотрез отказываются пускать через ebpf turing complete код, поэтому, конечно, в текущий момент интересный мне шедулер устроен крайне примитивно - в ядре выполняется только "простой" щедулер, который умеет в round robin внутри каких-то групп процессов, а решения по переносу процессов между группами (довольно медленно!) принимает userspace часть, которая уже и написана на rust (это было про другой шедулер) интересный мне шедулер устроен так - "This BPF backend implements the low level sched-ext functionalities for a user-space counterpart, that implements the actual scheduling policy. The BPF part collects total cputime and weight from the tasks that need to run, then it sends all details to the user-space scheduler that decides the best order of execution of the tasks (based on the collected metrics). The user-space scheduler then returns to the BPF component the list of tasks to be dispatched in the proper order" - не самое рекативное решение.

Понятное дело, что до полноценного сложного шедулера на ebpf пока еще очень далеко.

Будни #bootstrap.

Собрал себе ядро с PREEMPT_RT, а заодно с #sched_ext (https://t.iss.one/itpgchannel/2137)

Надо сказать, что веб страницы стали загружаться быстрее, и скроллинг в браузере на глаз лучше! Вы чо, ебу дали? Эффекты от этого можно будет найти только с лупой пока!

Да, да, -rcX, давно я так не развлекался, лет 20, наверное, не ставил rc ядро.

Это было не совсем тривиально, потому что для sched_ext понадобилось собрать ядро с clang. Раньше я всегда собирал с gcc, хотя вся остальная система собрана у меня с clang.

Наверное, какая-то инерция мышления, и желание собирать тем, чем собирали разработчики.

Но, в целом, факт того, что самая популярная в мире сборка ядра теперь на clang (да, да, ведроид), пошло ему на пользу, и собралось оно без плясок с бубном.

В общем, вроде, работает, не падает, буду экспериментировать с sched_ext дальше.

#sched_ext

Какие-то демонстрационные шедулеры у меня получилось заставить работать (но и результат, ожидаемо, никакой), а вот что-то серьезное уже не работает:

https://github.com/sched-ext/scx/issues/823

Товарищи захотели перехватить static функцию из ядра, которая у меня, например, заинлайнилась.

UPD:

В транке они это починили - https://github.com/sched-ext/scx/blob/fb3f1d0b43d8a1f69cbc434f4a43145dbd983076/rust/scx_rustland_core/assets/bpf/main.bpf.c#L258

Оно даже собралось, но зависло намертво. В том смысле, что машина зафризилась, без какого-то внятного debug.

Вышло ядро 6.12, https://www.opennet.ru/opennews/art.shtml?num=62243, и, наконец-то, у меня получилось завести #sched_ext.

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

Но тот эффект, который обещали авторы, воспроизвести пока не получилось.

Когда я запускаю компиляцию во все потоки, scx выходит через какое-то время, с ошибкой:

https://gist.github.com/pg83/602ee9f04e80d36d8651fec0e0af13d6

Начало положено, и, наверное, у меня скоро перестанет тормозить браузер (https://t.iss.one/itpgchannel/139)!

Ну и, конечно, очень приятно, что это не kernel panic, а вполне себе падение user space приложухи, которую можно перезапустить.

#sched_ext

История из серии "очумелые ручки".

В какой-то момент экспериментов с scx, я решил, что надо запускать userspace часть с каким-нибудь RT приоритетом, потому что решения про шедулинг - это важно, и нужно уметь получать их за предсказуемое время, да же?

Вот, сделал запуск через chrt -f 1 - https://github.com/pg83/ix/blob/main/pkgs/bin/scx/rust/land/runit/ix.sh#L5

И получил моментальный freeze всей системы, такие дела.

Так же попробовал bpfland, вместо rustland - по словам авторов, это то же самое, что и rustland, но полностью в ядре, в виде #ebpf программы https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_bpfland/README.md.

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

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

https://mostlynerdless.de/blog/2024/09/10/hello-ebpf-writing-a-linux-scheduler-in-java-with-ebpf-15/

Я в растерянности, потому что, с одной стороны, это годный текст про еще один userspace scheduler, на основе #sched_ext/#ebpf, а с другой - явный (pun intended) кандидат в серию "новости из дурки", потому что писать userspace scheduler на Java - это, конечно, за гранью.