commit -m "better"

commit -m "better"

#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 День, когда у меня перестанет тормозить браузер, все ближе и ближе…

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 пока еще очень далеко.

Phoronix

It's Looking Like sched_ext Will Try Again To Land For Linux 6.12

While Linus Torvalds was hoping to merge the sched_ext extensible scheduler for the Linux v6.11 kernel cycle, that didn't end up happening after some technical issues were raised on the kernel mailing list

www.tgoop.com/itpgchannel/2137

1.5K viewsedited  Aug 19, 2024 at 13:20

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 пока еще очень далеко.

BY commit -m "better"