Jaderné noviny – 15. 6. 2017: Zmenšování plánovače

18. 7. 2017 | Redakce | Jaderné noviny | 3029×

Stav vydání jádra. Elixir Cross Referencer. Plánování summitu správců. Citáty týdne: Ted Ts'o a Nicolas Pitre. Konec fedfs-utils. Zmenšování plánovače.

Stav vydání jádra

Současné vývojové jádro je 4.12-rc5, vydané 11. června. Podle Linuse je větší než většina jader v tomto cyklu. „Nejde o to, že by rc5 bylo *velké*, ale rozhodně není tak malé a hezké, jak jsem doufal. Nic [konkrétního] nevypadá znepokojivě a může to být jen o náhodné načasování – velikosti rc kolísají v závislosti na tom, který subsystém se synchronizuje s daným kandidátem na vydání, a možná, že jsme právě narazili na případ, kdy všichni synchronizují tento týden.“

Stabilní aktualizace: Verze 4.11.5, 4.9.32, 4.4.72 a 3.18.57 byly vydány 14. června.

Elixir Cross Referencer: nový způsob procházení zdrojových kódů jádra

Free electrons vydali úvodní verzi Elixir Cross-Referencer, což je nástroj pro prohlížení zdrojových kódů Linuxu s odkazy online. Elixir používá nový engine napsaný v Pythonu, který nahrazuje LXR, engine používaný v předchozím nástroji free electrons. „Další důvod, který vedl k úplnému přepsání, byl ten, že jsme chtěli poskytnout aktuální informace (včetně nejnovějších revizí) a zároveň je zachovat neměnné, takže by se externí odkazy ke zdrojovému kódu v budoucnu nerozbily. Přímým důsledkem by byla nutnost indexovat mnoho různých revizí každého projektu a mezi nimi by potenciálně mohlo být mnoho redundantních informací. Tehdy jsme si uvědomili, že můžeme využívat datového modelu Gitu, abychom se s touto redundancí efektivně vypořádali, a to indexováním blobů Gitu, které jsou mezi revizemi sdílené. Abychom zajistili, že při tomto přístupu budou dotazy dostatečně rychlé, napsali jsme verzi v Pythonu jako důkaz proveditelnosti, a tak se narodil Elixir.“

Plánování Summitu správců a Jaderného summitu 2017

Jaderný summit letos prochází jistými změnami. Hlavní shromáždění vývojářů z předchozích akcí bude nahrazeno půldenním „summitem správců“, kterého se zúčastní asi 30 lidí. Proces výběru těchto lidí a výběr témat pro otevřenou technickou sekci probíhal v době psaní článku. Více v oznámení.

Konec fedfs-utils

Chuck Lever oznámil, že končí s vývojem projektu fedfs-utils věnovaného nástrojům pro Federated Filesystem. Pro většinu čtenářů může být nejzajímavější tato diskuze o tom, proč se tento projekt zastavil. (Díky Neilu Brownovi.)

Citáty týdne

Realita je taková, že Linux je výsledkem úsilí dobrovolníků, takže jediné, nad čím má správce kontrolu, je (a) osobní čas, (b) jakékoli zdroje, které mu svěřil zaměstnavatel, (c) snažit se přesvědčit další lidi ve vývojářské komunitě, aby něco dělali (tento e-mail je toho příkladem , a nakonec za (d) správce může patchi říct NE. Snažím se co nejvíc upřednostňovat bod (c), ale pravdou je, že /dev/random je nejvíce sexy věc a abych byl upřímný, mám podezření, že existuje mnohem více zranitelných míst, na která jde zaútočit snáze než na generátor náhodných čísel. Takže ve skutečnosti může být _racionální_, aby se lidé, kteří pracují na tvrzení jádra, věnovali jiným oblastem.

—Ted Ts'o

A protože je celkem snadné napsat nový operační systém pro tak malé prostředí na zelené louce (a kdo nesnil o napsání vlastního operačního systému?), téměř každá firma v oboru to udělala. To nepočítám většinu open-source systémů, které jsou více méně projekty o jednom člověku. Takže výsledkem je velká roztříštěnost, velmi málo revidování a žádná iniciativa pro pořádnou správu, protože úspora nákladů za to prostě nestojí.

Je to jako asteroidy. Některé z nich se srazí, aby formovaly větší objekty jako planety, zatímco jiné mají příliš slabé gravitační pole, než aby přitáhly více hmoty. Má vize spočívá ve využití gravitační síly Linuxu, která by shromáždila malý vesmír embedded zařízení k sobě, protože sám o sobě nemá tento malý vesmír dost silnou komunitu, aby se sám zorganizoval.

—Nicolas Pitre

Zmenšování plánovače

Vzestupy a pády patchování jádra, aby se vměstnalo do malých systémů, se za poslední roky probíraly mnohokrát, naposledy v kontextu patchů alternativní vrstvy TTY Nicolase Pitra, zveřejněných v dubnu. Pitre vede debatu znovu, tentokrát se snaží zmenšit jaderný plánovač CPU. Během ní odhalil pár oblastí zásadního nesouhlasu o hodnotě práce tohoto druhu.

Pitre má za cíl umožnit spuštění systému založeného na linuxovém jádře na procesorech s kapacitou paměti jen 256 kB. Vyžaduje je to víc než jen zmenšit kód a datové struktury. Musí prostě eliminovat co nejvíce kódu. Patchi TTY nahradil subsystém TTY mnohem menší (a méně schopnou) alternativou. Jeho přístup k plánovači je jiný, hlavní plánovač zůstává, když jsou jeho patche aktivní, ale řada funkcí, včetně tříd plánovače deadline a realtime, je vynechána při překladu. Výsledný plánovač je o 25 % menší na úkor funkcí, které by v malých systémech stejně neměly využití.

Jak už to tak v případě „zmenšujících“ patchů bývá, dostalo se patchům plánovače mrazivého přijetí a Ingo Molnár je odmítl zcela. V následné diskuzi se objevily dva hlavní sporné body týkající se hodnoty těchto patchů.

Alan Cox tvrdil, že jádro nakonfigurované pro tak malé systémy už vlastně není Linux:

Takže jakmile jsi přepsal vrstvu TTY, ovladače zařízení, VFS a odstranil většinu systémových volání, proč ještě předstírat, že se jedná o Linux. Je to něco jiného a to něco jiného je architektonicky naprosto nekompatibilní s Linuxem. Což je mimochodem dobrá věc – snažit se nacpat Linux do takto malých zařízení není rozumné, protože tvé základní předpoklady o škálovatelnosti jsou zcela odlišné.

Jeho návrhem bylo vytvořit zcela nové jádro, které si půjčuje kousky zdrojových kódů Linuxu tam, kde se to hodí. Pitre odpověděl, že tento přístup byl vyzkoušen již mnohokrát, vždy bez úspěchu. Speciální jádra bývají většinou malé projekty s několika vývojáři. Postupují pomalu, jsou špatně udržovány a trpí na nedostatek kontroly kódu. Pitre doufá, že díky možnosti využít většinu linuxového jádra, včetně jeho ovladačů, se podaří shromáždit komunitu drobných systémů kolem jedné, dobře podporované alternativy.

Vedle toho Molnárův argument byl, že hodnota získaná podporou takových malých systémů nestojí za tu námahu, pokud jde o složitost kódu. Moorův zákon sice zpomaluje, ale schopnosti těchto systémů do budoucna porostou. Vzhledem k době, která uběhne mezi aplikací patche plánovače a jeho aplikací v distribucích a produktech – dva až pět let – už nemusí být po takovém patchi, v době kdy se objeví, poptávka. Proto je mnohem důležitější snížit složitost, nikoliv velikost plánovače:

Takže i když je jasné, že srovnání „složitost vs velikost jádra“ bude vždy výzvou k posouzení, co se plánovače týče, nejedná se o otevřenou otázku, co je třeba v této fázi udělat: potřebujeme omezit složitost a větve #ifdef, ne naopak.

Pitre s Molnárem nesouhlasil v každém bodě. Nejmenší systémy podle něj zůstanou malé z ekonomických důvodů:

Tvoje předpověď je založena na nesprávném předpokladu. Na IoT hardwaru, zvláště na tom nejlevnějším, se nedají vydělat žádné peníze. Tato malá zařízení se budou rozdávat zadarmo, protože peníze jsou v předplatném služby. Takže hardware musí být a bude extrémně levný na výrobu.

Poptávka po extrémně nízké spotřebě energie, aby systém mohl běžet měsíce nebo roky na jedinou baterii, bude udržovat tyto systémy malé. Co se týče časové prodlevy potřebné k přijetí těchto změn, Pitre zdůraznil, že velká část kódu souvisejícího s Androidem se do hlavního repozitáře dostala roky poté, co byla nasazena v produktech. Načasování má tendenci být v této části trhu obrácené. Také tvrdil, že jeho patche ve skutečnosti snižují složitost kódu plánovače tím, že rozdělují různé třídy plánovačů a umožňují jejich odstranění.

Konverzace nikam dál nepokročila. Jeden důležitý zlom však nastal, Molnár souhlasil s tím, že Pitreovy patche opravdu udržování plánovače usnadňují. Požádal, aby byly patche zaslány samostatně, aby mohlo dojít k jejich začlenění, což by podle něj mělo „ulehčit budoucí hádky.“ Pitre mu vyhověl, ale v době práce na tomto článku neproběhly žádné další diskuze o nových patchích. Pokud by patche byly přijaty, měly by být zbývající změny, které opravdu vyřazují tyto třídy plánovačů při překladu, poměrně malé.

Je zřejmé, že přimět ústřední správce jádra, aby přijali náklady spojené s podporou malých systémů, bude vždycky těžké. V tomto případě má komunita malých systémů vývojáře, který je odhodlán to dotáhnout do konce, je obeznámen s tím, jak vývoj jádra funguje, a je ochoten provést změny, aby došlo k začlenění patchů. Ani to samo o sobě stále není zárukou úspěchu v této značně obtížné, ne-li donquijotské, snaze, ale naděje jsou v tomto případě větší než u předchozích pokusů, které se – jak je vidět třeba tady a tady – příliš nevydařily.

       

Komentáře

[vlastikroot]

Me se zatim na jednojadrovych embedded systemech nejvic osvedcil BFS (Brain Fuck Scheduler).

[Salamek]

No nevim no... dneska je HW levnejsi nez prace programatora... natoz udrzovat nejaky vlastni obskurni fork Linuxu...

Dneska staci prakticky na vsechno RPI a na jednodusi veci Aurdino etc.