Роздуми про ядро

Від­ра­зу ска­жу, аби не викли­ка­ти нада­лі ніяких сум­ні­вів — Лінукс є най­кра­щою ОС в сві­ті. Все інше зво­ди­ться до цьо­го твер­дже­н­ня. Крім того, непо­свя­че­ні можуть від­ра­зу закри­ва­ти сто­рін­ку — роз'яснень основ­них понять я дава­ти не буду, тому таким осо­бам про­сто-напро­сто далі буде нудно чита­ти.

Слід­кую я за ядром, тоб­то за супро­во­джу­ю­чи­ми патча­ми, патчсе­та­ми, які регу­ляр­но ком­пі­лю, з вер­сії 2.6.17.8, тоб­то з… сер­пня 2006-го? Так вихо­дить? Якщо я не поми­ля­ю­ся. Хочу від­мі­ти­ти кіль­ка пун­ктів.

Швид­ко­дія. За більш-менш об'єктивною оцін­кою, яка вида­ва­ла­ся само­пи­сним ком­пле­ксним тестом, най­швид­шою з усіх вер­сій була 2.6.22 (з більш ран­ні­ми вер­сі­я­ми тести не про­во­ди­ли­ся, але за суб'єктивною оцін­кою, най­швид­ша — 2.6.17.14). Далі чомусь той же такий тест пока­зує зни­же­н­ня оцін­ки (їх насправ­ді три, пер­ша — інкре­мент змін­ної, дру­га — швид­кість систем­них викли­ків, тре­тя — швид­кість фор­ка; я спи­ра­ю­ся на остан­ній пока­зник як на най­більш ком­пле­ксний і об'єктивний). При­чи­ни тут оче­ви­дні — остан­нім часом роз­ро­бни­ки все швид­ше і швид­ше вно­сять змі­ни в код і, зда­є­ться, все мен­ше кон­тро­лю­ють його якість. Від цьо­го стра­ждає кін­це­вий кори­сту­вач. Так, нові фічі є, але ж і ста­рі лама­ю­ться досить часто (так зва­ні регре­сії). Зга­да­ти лише пола­ма­ний USB suspend у 2.6.25 на моє­му ста­ро­му ноу­ті. На цьо­му наче пра­цює нор­маль­но. Що далі буде — про­гно­зу­ва­ти не беру­ся. По-пер­ше, Лінус — чолов'яга своє­рі­дний, тому його ріше­н­ня перед­ба­чи­ти важ­ко. По-дру­ге, мій тест на цьо­му про­ці чомусь неаде­ква­тно себе веде в пара­лель­ній сво­їй части­ні. Може, це — пока­зник моєї кри­во­ру­ко­сті. Може, глюк ком­пі­ля­то­ра. А, може, бага SMP-ядра. Хоті­ло­ся б біль­ше віри­ти у пер­ше. Окрім того, повер­та­ю­чись до пока­зни­ків того ж тесту, зна­чні варі­а­ції (при чому бага­то­кра­тно отри­му­ва­ні) спо­сте­рі­га­ю­ться між різни­ми реліз-кан­ди­да­та­ми одні­єї і тієї ж вер­сії ядра. Не ска­жу, що деві­а­ції біль­ше поряд­ку зна­че­н­ня, але вони іно­ді скла­да­ють кіль­ка деся­тків від­со­тків, при чому бага­то­кра­тність вимі­рів зво­дить до нуля похиб­ку. Про єди­не жалію — не маю можли­во­сті аде­ква­тно порів­ня­ти резуль­та­ти попе­ре­дніх ядер з пото­чним через те, що змі­нив ноу­та. Але вики­нув­ши тест на пара­лель­ні пото­ки, можу хоча б порів­ня­ти 2.6.25-zen2 (пото­чне) і 2.6.26 (ваніль­не, а, можли­во, і з патчем zen1 тро­хи зго­дом). Резуль­та­ти ті самі — паді­н­ня швид­ко­сті фор­ку, паді­н­ня швид­ко­сті систем­них викли­ків і незна­чне зро­ста­н­ня інкре­мен­ту. Нада­лі мати­му змо­гу від­слід­ко­ву­ва­ти змі­ни більш впо­ряд­ко­ва­но.

Щоб дати під­твер­дже­н­ня сво­їм сло­вам, публі­кую резуль­та­ти:

kernel versioninteger increment (+1 per second)syscall (calls per second)fork (forks per second)dd (Mbytes per second)
Celeron 1300-based desktop with SDRAM (Debian Etch)
2.6.21.5‑rt14-krypton4111842056952120
2.6.21.5‑rt15-rubidium4105712058872244
2.6.21.5‑rt17-strontium4122872047951985
2.6.21.5‑rt18-yttrium4192982106702241
2.6.21.6‑cfs19-zirconium4362242179142387
2.6.22.1‑kamikaze2-update1-molybdenum2710891357752565
2.6.22.1‑kamikaze4-noalsacvs-technetium2622421315962271
2.6.22.1‑kamikaze5-noalsacvs-ruthenium2717151356692580
2.6.22-cfs19-niobium4568952282662478
2.6.22-kamikaze13309431665452577
Sempron Mobile 3100+-based notebook with DDR1 RAM (Debian Sid)
2.6.22.5‑cfs-v202939252184158488
2.6.22-kamikaze72560831279254230
2.6.22-kamikaze92703642183758505
2.6.22-klight24339502203988820
2.6.233330252143908572
2.6.23-kamikaze52648422168537538
2.6.23-l43734202054067325
2.6.23-rc83491642147178568
2.6.23-tiny12665522211727842
2.6.24364697290690728787,38
2.6.24-rc3-zen34578362859515551
2.6.24-rc4-zen1376550243156635595,85
2.6.24-rc6-zen0306914290663672062
Pentium Dual-Core T2330-based notebook with DDR2 RAM (Debian Experimental)
2.6.18–4‑68624992412891747892259,81
2.6.24–1‑68636028318552140492801,89
2.6.25–2‑68636445218446039112779,79
2.6.25-zen237204218554331872808,89
2.6.2638018019013629602816,23
Athlon 64 X2 Dual Core 4200+-based desktop with DDR2 RAM (Debian Lenny)
2.6.22–3‑amd6416397311390557832194,58
2.6.24–1‑amd6429383818641151452598,31
2.6.25–2‑amd6420078513978244812383,63

Вихі­дний код теста:

program osbench4;
 
uses sysutils;
 
const
      blocksize=16384;
 
var
    i:longint;
    res, et:extended;
    {$ifdef unix}
    fin, fout:file of byte;
    buffer:array[1..blocksize] of byte;
    cbt, cet, speed:extended;
    numread, numwritten:longint;
    count:extended;
    {$endif}
 
begin
  if paramcount=0 then
     begin
       (*benching single increment*)
       write('Single increment value: ');
       et:=now+1/86400;
       i:=0;
       repeat
         inc(i);
       until now>=et;
       writeln(i);
       (*benching system call*)
       write('Single system call value: ');
       et:=now+1/86400;
       i:=0;
       repeat
         res:=now;
         inc(i);
       until now>=et;
       writeln(i);
       (*benching executing process*)
       write('Single executing process value: ');
       et:=now+1/86400;
       i:=0;
       repeat
         {$ifdef unix}
         executeprocess('./single_child', '');
         {$else}
         executeprocess('.\single_child.exe', '');
         {$endif}
         inc(i);
       until now>=et;
       writeln(i);
       (*test copying from /dev/zero to /dev/null, ONLY FOR LINUX*)
       {$ifdef unix}
       write('Speed of copying from /dev/zero to /dev/null (blocksize=', blocksize, ' bytes): ');
       assign(fin, '/dev/zero');
       reset(fin);
       assign(fout, '/dev/null');
       rewrite(fout);
       count:=0;
       cbt:=now;
       cet:=cbt+10/86400;
       repeat
         blockread(fin, buffer, blocksize, numread);
	 blockwrite(fout, buffer, numread, numwritten);
	 count+=numwritten;
       until (now>=cet) or
             (numread=0) or
	     (not (numread=numwritten));
       speed:=count/(10*1024*1024);
       writeln(speed:1:4, ' Mb/sec');
       {$endif}
     end
       else
         begin
           writeln('osbench4 by Oleksandr Natalenko aka post-factum, 2007-2008');
           writeln('Distributed under terms and conditions of UPLv3.1 (see file COPYING for details)');
           {$ifdef unix}
           writeln('Usage: ./osbench4');
           {$else}
           writeln('Usage: osbench4');
           {$endif}
         end;
end.
program single_child;
begin
end.

Спо­ча­тку ком­пі­ли­ться пер­ший файл: fpc osbench4.pp, потім дру­гий: fpc single_child.pp. Бінар­ні фай­ли кла­ду­ться в один ката­лог, і запу­ска­є­ться osbench4.

Висно­вок. Кудись діва­є­ться кін­це­ва швид­кість робо­ти ядра.

Фіча­стість. Тут така собі медаль з дво­ма сто­ро­на­ми. Гар­на сто­ро­на — можли­во­сті ядер ростуть, як у бік про­сто­го кори­сту­ва­ча, так і в бік роз­ро­бни­ків. І це, без­сум­нів­но, є вели­ким про­гре­сом — вво­ди­ться під­трим­ка ново­го залі­за, нових техно­ло­гій, які дозво­ля­ють роби­ти свою спра­ву про­ду­ктив­ні­ше, зру­чні­ше, лег­ше. Інша сто­ро­на — зга­да­ні регре­сії, які сто­су­ю­ться не лише швид­ко­сті робо­ти. Постій­но дода­ю­ться нові помил­ки, хоча ста­рі і при­би­ра­ю­ться, постій­но вини­ка­ють нові про­бле­ми, які при­зво­дять до непра­виль­ної робо­ти кри­ти­чних (я б ска­зав, край­ніх) частин ядра (напри­клад, ACPI з суспен­дом). І хоча все це потім, рані­ше або пізні­ше, але бере­ться до ува­ги і при­во­ди­ться до нале­жно­го ста­ну, факт лиша­є­ться фактом — ядро "бур­лить", як борщ під час готу­ва­н­ня.

Висно­вок. Фічі фіча­ми, але ста­біль­ність також необ­хі­дна.

Модель роз­роб­ки. Про пере­ва­ги опен­со­ур­сної моде­лі роз­роб­ки писа­ло­ся дуже бага­то, я не зби­ра­ю­ся її запе­ре­чу­ва­ти, але саме така модель, яка прийня­та в роз­роб­ці ядра Ліну­кса, при­зво­дить до вище­зга­да­них про­блем. На мою дум­ку, необ­хі­дно чітко роз­ді­ля­ти ста­біль­ну і неста­біль­ну гіл­ку, при­чо­му так, щоб їх було дві, а не стіль­ки, скіль­ки роз­пло­ди­ло­ся остан­нім часом. Це вно­сить непо­ро­зу­мі­н­ня для заці­кав­ле­но­го кори­сту­ва­ча, який не знає, що і для чого він має вико­ри­сто­ву­ва­ти. Тоб­то вар­то прийня­ти ріше­н­ня повер­ну­ти­ся до ста­ро­го сві­то­с­прийня­т­тя — парні/непарні вер­сії. І запро­ва­ди­ти роз­роб­ку гіл­ки 2.7.x. Крім того, одно­о­сі­бне прийня­т­тя рішень, хай то буде на рів­ні під­си­стем з їхні­ми мейн­тей­не­ра­ми, чи на вищо­му рів­ні (в облич­чі Ліну­са) не зав­жди при­зво­дить до пози­тив­них зру­шень (reiser4, kgdb, realtime, ck — далі пере­ра­хо­ву­ва­ти?). І хоча части­на рішень рано чи пізно в ядро вхо­дить (kgdb, uvesafb), а інша через якісь тупі непо­ро­зу­мі­н­ня про­сто від­ки­да­є­ться (ck-патчсет, reiser4). Необ­хі­дне коле­ктив­не прийня­т­тя рішень за уча­сті біль­шої кіль­ко­сті людей про­стим голо­су­ва­н­ням. Все це нага­ду­ва­ло б такий собі своє­рі­дний форум, де можна нор­маль­но бути почу­тим, про­чи­та­ти, поспе­ре­ча­ти­ся і, вре­шті-решт, про­го­ло­су­ва­ти для прийня­т­тя ріше­н­ня.

Висно­вок. Роз­ро­бни­кам не слід забу­ва­ти про про­стих смер­тних, і що Лінукс дав­но виріс із ста­ту­су "ігра­шки" і пере­йшов у ста­тус сер­йо­зно­го інстру­мен­ту, яким кори­сту­ю­ться люди, і який пише­ться для людей, а не для себе. Не тре­ба нехту­ва­ти їх інте­ре­са­ми.

Дрі­бні при­ко­ли. Різній фігні типу змі­ни нуме­ра­ції ядра при­ді­ля­є­ться над­то бага­то ува­ги. І замість того, щоб, напри­клад, поси­ле­но зби­ра­ти від юзе­рів пові­дом­ле­н­ня про помил­ки (вклю­че­н­ня за змов­чу­ва­н­ням kerneloops'а, напри­клад) і пра­цю­ва­ти над їх виправ­ле­н­ням, деве­ло­пе­ри дис­ку­ту­ють нав­ко­ло оче­ви­дних і тупих питань.

Висно­вок. Вар­то про­сто кон­цен­тру­ва­ти­ся на речах, більш важли­вих, аніж нуме­ра­ція.

Загаль­ний висно­вок. Ядро не іде­аль­не. Роз­ро­бни­ки теж люди. Але в пла­ні орга­ні­за­ції про­це­су є куди роби­ти рішу­чі кро­ки для під­ви­ще­н­ня про­ду­ктив­но­сті робо­ти (яка, між іншим, на 75% є опла­чу­ва­ною). І не вар­то кри­ча­ти, яке ядро пога­не. Воно, насправ­ді, згі­дно тих реа­лій, які супро­во­джу­ють його роз­роб­ку, дуже гар­но зро­бле­не. І від­сту­па­ти ніку­ди — ні на він­ду через глю­ка­вість, ні на макось через її пере­бір­ли­вість і при­ві­ле­йо­ва­ність.

P. S. Кри­ти­ка віта­є­ться.

Мітки: , ,

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

*

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.