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 - это, конечно, за гранью.