commit -m "better"

@itpgchannel

just random thoughts

commit -m "better"

22 Oct, 15:41

Меня тут спрашивают, зачем мне realtime (PREEMT_RT) ядро.

Мол, realtime - это не про скорость, все будет медленнее.

Я утверждаю, что нет вообще никакого смыcла (ну, кроме пока не отлаженных багов) не использовать PREEMT_RT, а использовать что-то другое.

Смотрите, Linux имеет несколько "классов" шедулинга. Условно говоря, realtime, "обычные процесы", "фоновые процесы" (я упрощаю специально, для ясности).

И если у вас в системе нет realtime процессов, то (за очень небольшим числом исключений, я про них знаю, но они не меняют сути происходящего) наличие full PREEMT_RT шильдика вообще никак не влияет на вашу нагрузку.

Потому что шедулинг устроен примерно так - ядро шедулит сначала RT процессы, в соответствие с их RT приоритетом, а в "остатки" процессорного времени уже шедулит все оставшиеся процессы. И, если у вас нет RT процессов, то "остаток" всего CPU - это 100% CPU, которое "обычным образом" распределяется между остальными классами процессов и процессами.

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

Ну и, для полноты картины, приведу пример процессов, которые у меня уже прямо сейчас RT:

* Звуковой демон (мультиплексор). Когда мне нужно проиграть звук, то мне нужно, чтобы он попал в звуковую карту ровно тогда, когда нужно, чтобы не было всяких там "пш-пш". Поэтому мой #sndiod должен иметь право разогнать вообще всех, не только фоновый компилятор clang, а еще и условное прерывание дисковой подсистемы, или там сетевухи.

* D-Bus broker. Это, с ходу, может быть не очень очевидным, но всякого рода message passing может (очень легко!) стать причиной https://en.wikipedia.org/wiki/Priority_inversion, и, поэтому, на всякий случай, dbus стоит сделать RT процессом, чтобы он уж точно не стоял на пути "важного" сообщения.

Есть "серые зоны".

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

580

commit -m "better"

22 Oct, 10:28

Админ за работой.

1,038

commit -m "better"

21 Oct, 21:52

#nix

https://determinate.systems/posts/announcing-determinate-nix/

Гля какая красота, в ответ за то, что ~~квадроберы~~ фурри его пидорнули из Nix, чувак взял, и запилил форк.

Причем, насколько я помню историю, форк этот подкреплен понятными ресурсами.

Запасаемся попкорном!

1,174

commit -m "better"

21 Oct, 20:28

https://habr.com/ru/news/851968/

TL;DR - хорошо мотивированный стажер может горы свернуть!

1,222

commit -m "better"

21 Oct, 19:17

Будни #bootstrap

Клал я новую версию libunistring (это такое оверинжиниренное говно для работы с unicode, от проекта #GNU), и там что-то сломалось под aarch64.

Что именно, для рассказа неважно, там в тестах заюзали непортабельную хрень, решил я это, как обычно, грубо и эффективно - https://github.com/pg83/ix/blob/main/pkgs/lib/unistring/ix.sh#L26-L27

Пока я с этим разбирался, наткнулся на смешной комментарий в коде:

/* Work around clang bug <https://github.com/llvm/llvm-project/issues/104670> */

"clang bug" от сумасшедших GNU мейнтейнеров - это должно быть очень весело, подумал я!

https://github.com/llvm/llvm-project/issues/104670

Там, действительно, какое-то несоответствие между тем, как работает gcc, и как работает clang (macro expansion в pragma - должно или не должно случаться?)

Мне очень понравилось, как коллега аргументирует, что это именно баг в clang:

"I claim that this is a bug, because

* With "gcc" instead of "clang", it works fine.
* The documentation at https://gcc.gnu.org/onlinedocs/gcc/Weak-Pragmas.html does not mention effects of macro definitions"

Сука, в этот момент я, конечно, взорнул, да.

Правда, там чуть ниже есть настоящая причина, почему это баг (standalone пропроцессор в clang работает не так, как если бы он был встроен):

"* If I preprocess main.c before compiling it, it works fine as well"

Наверное, у коллеги просто такое специфическое чувство юмора.

Еще забавно, что в этот тикет набижал главный мейнтейнер gcc, и рассказал эту печальную историю, откуда пошло такое поведение - https://github.com/llvm/llvm-project/issues/104670#issuecomment-2294994641 (спойлер - все грустно).

Оказалось, что https://github.com/pinskia регулярно набигает в багтрекер llvm, и рассказывает, где clang и gcc не совпадают, очень хорошее дело, я считаю.

А пока я вспоминал, кто же такое pinskia, наткнулся на замечательный срачик Тео Де Раадта с мейнтейнерами gcc, про его скорость - https://gcc.gnu.org/legacy-ml/gcc/2004-03/msg00011.html

1,001

commit -m "better"

20 Oct, 18:34

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

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.

1,232

commit -m "better"

20 Oct, 12:59

Будни #bootstrap.

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

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

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

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

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

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

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

1,250

commit -m "better"

20 Oct, 09:55

Мотивация должен быть всегда 😎

ФГ

1,198

commit -m "better"

20 Oct, 08:37

Мне кажется, эти новости хороши вместе:

https://www.opennet.ru/opennews/art.shtml?num=62078

"Работа ведётся совместно с компанией 9elements, специализирующейся на адаптации CoreBoot для различного оборудования"

Напомню, 9elements - это компания, из-за которой ноутбуки от malibal теперь не поставляются в Германию!

1,293

commit -m "better"

20 Oct, 08:20

Вообще, конечно, всего 3 года от "владелец пакета может выбирать, с каким компилятором он собирается" (https://t.me/itpgchannel/13), до "наш сотрудник - lead maintainer llvm", это уметь надо :))

1,218

commit -m "better"

19 Oct, 07:43

https://www.malibal.com/features/dont-support-the-coreboot-project/

Очень странная и смешная история.

Производитель ноутбуков решил заюзать https://www.coreboot.org/, за 15 меяцев поменял трех консультантов (которые, так или иначе, участвовали в разработке coreboot), и, все равно, остался ни с чем.

В процессе так разозлился на этих консультантов, что решил:

* Не поставлять свои ноутбуки в Германию https://portal.malibal.com/kb/a1060/why-dont-you-ship-to-germany/
* ... в Польшу (это все откуда были консультанты!) https://portal.malibal.com/kb/a1061/why-dont-you-ship-to-poland/
* ... штату Техас! https://portal.malibal.com/kb/a1058/why-dont-you-ship-to-texas/
* и, вишенка на торте, отказался от использования AMD в своих ноутбуках! https://portal.malibal.com/kb/a1059/why-dont-you-offer-any-amd-processors-or-graphics/

Совершенно феерический текст, почитайте.

1,982

commit -m "better"

18 Oct, 18:14

https://www.phoronix.com/news/LLVM-Lead-Maintainer-Popov

Ня какая красота!

"Red Hat Engineer Nikita Popov Now The Lead Maintainer For LLVM"

Теперь IBM/RH один из главных stakeholder'ов не только в GCC, но и в LLVM!

1,419