Инго Молнар (Ingo Molnar) представил вторую версию набора патчей, позволяющего значительно сократить время пересборки ядра за счёт реструктуризации иерахии заголовочных файлов и сокращения числа перекрёстных зависимостей. От предложенной несколько дней назад первой версии новый вариант отличается адаптацией для ядра 5.16-rc8, добавлением дополнительных оптимизаций и реализацией поддержки сборки с использованием компилятора Clang. При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77% в показателях расходования ресурсов CPU. При полной пересборке ядра командой "make -j96 vmlinux время сборки сократилось с 337.788 до 179.773 секунд...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56475
фантастика, ждем в апстриме
фантастика что новости уже пару дней, а про 96 и 69 еще никто не пошутил :(
не играет гормон и это печально, стареете
Титанический труд, спасибо всем причастным за проделанную работу!
ага, большое спасибо за сломанный blame по всему ядру. надеюсь, причастных когда-нибудь посадят
> сломанный blameЭто такая дешёвая придирка, что просто смешно. Случаи, когда git blame за один заход помогает найти оригинального автора настолько редки, что можно смело считать, что такого не происходит никогда. Всегда после запуска git blame нужно проверять патч, чтобы выяснить суть изменений. Иногда это реструктурирование кода, иногда функции приобретают или теряют аргумент. Иногда приличный кусок кода смещается вправо или влево, потому что добавился или исчез "if". Всегда нужно проверять патч.
В долгоживущих проектах git blame может состоять из более чем десятка шагов. Ещё один шаг погоды не делает.
Да забей. "Свинья везде грязь найдет"
а в Винде как такую проблему решили? там же тоже ядро на си...
А зачем майкам решать такую проблемы у них же человекочасы и количество фич на релиз кипиай. Им никакие оптимизации не нужны.
Начиная с 10 винды у них ядро спроектирвоано самим Линусом с нуля. Так что наверняка он уже применил более продвинутые подходы, учитвая свой опыт, которые только приходят в линукс.
Абсолютно непрофессиональные люди из сферы IT минусуют или как это работает? Это просто факт и мнение построенное на нём.
Вот так:private\windows\media\avi\verinfo.16\verinfo.h:
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!IF YOU CHANGE TABS TO SPACES, YOU WILL BE KILLED!!!!!!!
* !!!!!!!!!!!!!!DOING SO F*CKS THE BUILD PROCESS!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Да, было веселье, когда комментарии в утекшем коде винды разбирали.Вот ещё находки (источник https://web.archive.org/web/20040622090121/http://www.kuro5h... ):
private\shell\shell32\util.cpp:
// the fucking alpha cpp compiler seems to fuck up the goddam type
"LPITEMIDLIST", so to work<BR>// around the fucking peice of shit compiler we
pass the last param as an void *instead of a LPITEMIDLIST
private\ntos\rtl\heap.c:
// The specific idiot in this case is Office95, which likes
// to free a random pointer when you start Word95 from a desktop
// shortcut.private\ntos\w32\ntuser\kernel\swp.c:
* for idiots like MS-Access 2.0 who SetWindowPos( SWP_BOZO
* and blow away themselves on the shell, then lets
* just ignore their plea to be removed from the trayprivate\ntos\w32\ntuser\kernel\swp.c:
* for idiots like MS-Access 2.0 who SetWindowPos( SWP_BOZO
* and blow away themselves on the shell, then lets
* just ignore their plea to be removed from the trayprivate\inet\mshtml\src\core\cdbase\baseprop.cxx:
// HACK! HACK! HACK! (MohanB) In order to fix #64710 at this very late
private\inet\mshtml\src\core\cdutil\genutil.cxx:
// HACK HACK HACK. REMOVE THIS ONCE MARLETT IS AROUNDprivate\inet\mshtml\src\other\moniker\resprot.cxx:
//
goto EndHack;
//private\inet\mshtml\src\site\layout\flowlyt.cxx:
// God, I hate this hack ...private\inet\wininet\urlcache\cachecfg.cxx:
// Dumb hack for back compat. *sigh*private\inet\wininet\urlcache\filemgr.cxx:
// ACHTUNG!!! this is a special hack for IBM antivirus softwareprivate\ispu\pkitrust\trustui\acuictl.cpp:
// HACK ALERT, believe it or not there is no way to get the height of the current
// HACK ON TOP OF HACK ALERT,private\ntos\udfs\devctrl.c:
// Add the hack-o-ramma to fix formats.private\shell\shdoc401\unicpp\sendto.cpp:
// Mondo hackitude-o-rama.private\ntos\w32\ntcon\server\link.c:
// HUGE, HUGE hack-o-rama to get NTSD started on this process!private\ntos\w32\ntuser\client\dlgmgr.c:
// HACK OF DEATH:private\shell\lib\util.cpp:
// TERRIBLE HORRIBLE NO GOOD VERY BAD HACKprivate\ntos\w32\ntuser\client\nt6\user.h:
* The magnitude of this hack compares favorably with that of the national debt.private\shell\ext\tweakui\genthunk.c:
* CallProc32W is insane. It's a variadic function that uses
* the pascal calling convention. (It probably makes more sense
* when you're stoned.)private\mvdm\wow32\wcntl32.c:
// These undocumented messages are used by Excel 5.0private\mvdm\wow32\wgdi31.c:
// InquireVisRgn is an undocumented Win 3.1 API. This code has been
// suggested by ChuckWh. If this does not fix the s 2.0
// problem, then ChuckWh would be providing us with an private entry
// point.private\mvdm\wow32\wgfont.c:
* This thunk implements the undocumented Win3.0 and Win3.1 API
* GetCurLogFont (GDI.411). Symantec QA4.0 uses it.
* To implement this undocumented API we will use the NT undocumented API
private\ntos\w32\ntuser\kernel\mnpopup.c:
// Set the GlobalPopupMenu variable so that EndMenu works for popupmenus so
// that WinWart II people can continue to abuse undocumented functions.private\windows\shell\accesory\hypertrm\emu\minitel.c:
// Guess what? Latent background color is always adopted for mosaics.
// This is a major undocumented find...private\windows\shell\accesory\hypertrm\emu\minitelf.c:
// Ah, the life of the undocumented. The documentation says
// that this guys does not validate, colors, act as a delimiter
// and fills with spaces. Wrong. It does validate the color.
// As such its a delimiter. If...
Надеюсь сломают всю совместимость чтобы все старые версии пошли по-бороде. И все перешли с нафталиновых ядер на новые.
изменений в рантайме особых быть не должно
А при чем тут рантайм? Они постоянно свой API ломают (причем даже внутри версии), что постоянно вызывает проблемы с модулями вне ядра.
в сторонних модулях придется поправить инклюды (может потребоваться подключить то что подключалось раньше через какой нибудь sched.h)Собсно апи там вроде не ломали
А при чём тут апи?
Так-то оно API не ломает.
ABI может по известной вещи пойти, но это уже не так критично.
Как не ломает? Набор #include - тоже часть api.
Авторам 3d party модулей не привязанным исключительно к "linux-next" (нвидии или zol) работенка светит немалая. Полагаю, потраченное время будет несоизмеримо с копейками выигрыша от пересборки на аж 96 ядрах - но это кого надо выигрыш, он себе карты сам и сдает.А что в ядре полно г-нокода - так он и не денется никуда.
(одни мегабайтные списки usb idшек намертво вбитые в код чего стоят - и нет, ты не можешь передать нестандартные параметром. Иди пересобирай ведро. Каждый раз как сасунь выпускает новый телефон.)
Ну, тогда тут немножко шире, чем ломает-не ломает, раз мы в дебри полезли.- Собранному софту не поплохеет, userspace API не ломается
- В исходниках софта, завязанного на include хедеров ядра, возможно, потребуются правки
- В исходниках сторонних модулей ядра, скорее всего, потребуются правки
- Собранные сторонние модули ядра традиционно сломаются :), но не из-за конкретных изменений, а просто потому, что их всё равно под каждую конкретную версию ядра собирать надо
На ядрах, начиная с 5.13, suspend-to-ram сломан. Я лучше на 5.11 посижу.
Об этом кроме тебя кто-нибудь знает?
А у меня он начиная с 5.1x исправлен.
Надейся, надейся...
> адаптацией для ядра 5.16-rc8кстати, а до этого под какое ядро было?
5.16-rc7
5.16-rc7
> При использовании Clang применение патчей позволило сократить время сборки на 88%
> При полной пересборке ядра командой "make -j96 vmlinux время сборки сократилось с 337.788 до 179.773 секунд.кто кого изнасиловал? качество копипастного перевода прихрамывает
Эмм, что-то не знаю, с одной стороны - круто, с другой стороны подозреваю, что во-первых - это усложнит дальнейшую разработку, т.к. ПМСМ - хочется видеть доступные библиотеки и возможности в начале заголовка, а не надеятся, что какой-нибудь Вася его подключил за тебя, плюс - вот 100% можно было либо кэширующим компилятором, либо инструментом предобработки обойтись, вместо того, чтобы ядро целиком патчить. Т.е. надеюсь не окажется, что вся эта работа - выстрел в ногу разработчикам от очередных фанатов утилиты time.
> Инго Молнар (Ingo Molnar)Это который создал 12309?
Выстави:
vm.overcommit_memory = 2
vm.overcommit_ratio = 200
и перестань плакаться.P.S. Нет, 12309 создал Ben Gamari https://web.archive.org/web/20200206024633/https://bugzilla....
это тот анекдот - "подожди сейчас дискету доформатирую" но для Linux
> это тот анекдот - "подожди сейчас дискету доформатирую" но для LinuxТы можешь анекдот, как угодно перекладывать. Ну а linux можно тюнить под задачи - хочешь что-бы тормозило, как в форточках95 при форматировании дискет, можешь и под это затюнить - никто тебя в этом не ограничивает.
лучше б занялись оптимизацией работы, компилится ядро раз в несколько месяцев, и обычнона стороне производителя дистрибутива, а вот выполнение кода происходит каждую секунду. но это сложно, проще поиграть в хареке и солонку :) попутно дооптизимировав исходники в бинарное-vscode-only нечтно (зато быстро!)
Автору патча напиши чтобы он му*ак занялся наконец делом, а не вот этой ненужной для анонимусов оптимизацией
его уже поперли с шедулера, он другую ненужную хрень сделать решил.
А че - шапка все оплатит.
>При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77%Не понимаю зачем заниматься компилятором Clang? Пусть это поделие корпорастов идёт к чёрту.
Только, и только божественный GCC!!!!!!!
> Пусть это поделие корпорастов идёт к чёрту.Согласен, да только ядро на 80-90% пилится ими
Да хоть для того чтобы gcc не скатывался в не пойми что, как это было лет 8 назад.
очень надо были это все c++2k22 в гцц, кушатьнимагли
Когда уже под tcc пропатчат?
Оно собиралось tcc.
Ещё бы прокрутку в консоли починили.
Лучше бы само ядро пропатчили. С каждым релизом всё более неповоротливое становится. То BFQ, то btrfs ломают, то симптомы 12309 всё ещё остаются... Никакие настройки не помогают. Торвальдс там что, вообще положил болт на разработку? А раньше же так хорошо работало, фору любой другой системе дал бы, а сейчас...
Bfq перманентно сломан с первых дней, это кем надо быть чтобы его юзать? Чтобы избавиться от 12309 всегда было достаточно его отключить (с тех пор, как на mq перевели дефолт, даже ядро настраивать на надо).
facepalmчувак не вкурсе про
#pragma once
Что ж ты строем не ходишь, раз такой умный?
j96 круто конечно, а на более доступных Core i5 какое время этот патч сэкономит?
кому ты интересен - когда IBM сказало пилить ?!
у них на power тормозит.
Посчитайте пропорцию от текущего времени соборки. В абсолютных цифрах на "слабых" процессорах экономия существеннее.
-j96?? ребята на ЭПЫКах сидят, поди...PS: почистили ненужное инклюдное Г - молодцы. Я тоже так делал. Кучу лет назад. Вручную. А когда завезли многопоточность, проект стал компилиться за минуту вместо получаса )