Fastboot: aszinkron függvényhívások a kernel boot idejének csökkentése érdekében

Címkék

Tavaly október elején már volt szó arról, hogy az Intel alkalmazásában álló Arjan van de Ven azon dolgozik, hogy csökkentse a Linux kernel hajtotta rendszerek boot idejét. Most a fejlesztő elküldte az LKML-re frissített "fastboot" patchset-jét.

Jelenleg a kernel boot nagy része szinkron módon zajlik és ez nem valami gyors, mert a hardverek inicializálásából származó késedelmek egymást követően jelentkeznek. Annak érdekében, hogy a kernel gyorsabban bootoljon, a patchset egy olyan mechanizmust vezet be, amely lehetővé teszi egyes inicializációs lépések aszinkron végrehajtását, s ez a gyakorlatban "elrejti" az ebből adódó késedelmek egy jelentős részét.

Idézet a patch-ből:

Goals and Theory of Operation

The primary goal of this feature is to reduce the kernel boot time,
by doing various independent hardware delays and discovery operations
decoupled and not strictly serialized.

More specifically, the asynchronous function call concept allows
certain operations (primarily during system boot) to happen
asynchronously, out of order, while these operations still
have their externally visible parts happen sequentially and in-order.
(not unlike how out-of-order CPUs retire their instructions in order)

Key to the asynchronous function call implementation is the concept of
a "sequence cookie" (which, although it has an abstracted type, can be
thought of as a monotonically incrementing number).

The async core will assign each scheduled event such a sequence cookie and
pass this to the called functions.

The asynchronously called function should before doing a globally visible
operation, such as registering device numbers, call the
async_synchronize_cookie() function and pass in its own cookie. The
async_synchronize_cookie() function will make sure that all asynchronous
operations that were scheduled prior to the operation corresponding with the
cookie have completed.

Subsystem/driver initialization code that scheduled asynchronous probe
functions, but which shares global resources with other drivers/subsystems
that do not use the asynchronous call feature, need to do a full
synchronization with the async_synchronize_full() function, before returning
from their init function. This is to maintain strict ordering between the
asynchronous and synchronous parts of the kernel.

A bejelentés itt olvasható.

Hozzászólások

Kivancsi leszek a hatasara. 2.6.30 talan?

Véleményem szerint ez a jó út, hisz már régóta vannak 2 magos processzorok és az i7 szériában már csak 4 magosak vannak. Ha szinkron módban fut a boot akkor a maradék 1-3 mag kihasználatlan maradhat, illetve nem optimális a kihasználtsága.

A programok fejlesztői egyre jobban törekednek a threadek használatára, hogy szoftverjük optimálisabban használja ki a hardvert és gyorsabb futást produkáljon.
Miért ne fejlődhetne ebbe az irányba a kernel is?

-- Ubuntu --

zsír. akkor hamarosan 3 mp-vel többet fog rám várni a login screen, amíg visszaérek a gép elé bekapcsolás után. ez valóban megéri a fáradozást :)

Rosszul fogalmaztad meg a kérdést.

A teljes uptime kis százaléka is lehet idegesítő, ha nem tudsz a rendszerrel hasznos munkát végezni mint például a hupon posztolni.

A laptopok, netbookok, embedded felhasználáson kívül ez egy desktopnál is számít. Nem mindegy, hogy 5-10 másodperc múlva ott a login prompt és utána a használható desktop vagy ez 50-60 másodpercet vesz igénybe.

A leállításra ugyanez vonatkozik egyébként.

Persze lehet azzal az érvvel jönni, hogy minek olyan gyors boot és kit érdekel, de van akit érdekel és van akinek hasznos. Attól, mert neked nem jut eszedbe példa az nem jelenti azt, hogy nincs.

Konkrétan az esetemben is 5-10mp boot idővel tömegközlekedésen elővenném néha a laptopot/netbookot, egy perc boot esetén meg nem valószínű.

Arról nem szólva, hogy ez akár szerverkörnyezetben is hasznos lehet azok számára akik a load alapján indítanak illetve állítanak le rendszereket ezzel erőforrásokat kímélve.

"Linux boot 5 másodpercen belül"

igen. fölösleges szolgáltatások kilövésével, initrd és egyéb sallang lepucolásával, kernel fordítgatással-patcheléssel, hdd olvasás hegesztésével, mindezt egyetlen specifikus gépre kihegyezve. tehát hogy is jön ez ide? :)

hint: most a boot idő lerövidítése 1/10-edére a hw inicializálás optimalizálásával a téma, nem más

"hint: most a boot idő lerövidítése 1/10-edére a hw inicializálás optimalizálásával a téma, nem más"

Egy cseppet mintha el lennél tévedve.

szerk.: szájbarágósabban: a téma az, hogy ki mit szólna a töredékére rövidült boot időhöz. Hogy az 50 másodpercről 5-re gyorsulás pusztán aszinkron hardver inicializálással elérhető lenne, az már csak a te agyszüleményed.

"Jelenleg a kernel boot nagy része szinkron módon zajlik és ez nem valami gyors, mert a hardverek inicializálásából származó késedelmek egymást követően jelentkeznek. Annak érdekében, hogy a kernel gyorsabban bootoljon, a patchset egy olyan mechanizmust vezet be, amely lehetővé teszi egyes inicializációs lépések aszinkron végrehajtását, s ez a gyakorlatban "elrejti" az ebből adódó késedelmek egy jelentős részét."

muszáj tenni a hülyét?

oké, leírom:

- dejó, 5 mp-vel gyorsabb lesz a boot [az aszinkron hardver inicializálás miatt]
- fasság, netbooknál fontos az, 5 mp-vel kevesebb ideig merül az akksi [az aszinkron hardver inicializálás miatt]
- az mennyi is a teljes üzemidőből?
- hülye kérdés, én sokat kapcsolgatom, így még jobb lesz nekem [az aszinkron hardver inicializálás miatt], mert 5-10 mp lesz a boot 1 perc helyett, és a bkv-n is kockulhatok majd

Az van hogy ezek a néhány másodperces kis lefaragások összeadódnak, tehát azért talán mégsem mindegy. Örülök hogy nem csak az init scriptekkel bűvészkednek, hanem a kernellel is, meg mindennel amivel nyerni lehet. (apránként, de sok kicsi sokra megy)

--
"Dude, you can't take something off the Internet.. that's like trying to take pee out of a swimming pool."

Százalékban nagyon kevés, de az idő szubjektív. Amikor egy átlag felhasználó bekapcsol egy gépet azért teszi, mert éppen valamit akar tőle - azaz a feladatra van hangolva. Ha 1-2 percet várnia kell elkalandozik a figyelme a feladatról, csökken a motiváltság, elmegy az ihlet...
Én örülnék egy gyors bootnak - jó lenne a gyors hibernálás is helyette, de nincsenek túl jó tapasztalataim a visszatérést illetően.

Volt itt a HUPon is, hogy valakik csináltak gyorsbootot, úgy szervezték meg az init által indított szolgátatások időzítését, hogy egy-egy erőforrást (szűk keresztmetszetet) egyszerre egy induló processz használjon. Meg ugye csináltak kerneloldalra egy caching-ot, és ha jól emlékszem 5-6 sec lett így a boot? Na ha ehhez hozzágondolod a fenti fastboot-ot, akkor előbb kapsz x-et, mint képet a monitorra :)

"és ha jól emlékszem 5-6 sec lett így a boot? Na ha ehhez hozzágondolod"

De ne gondold hozzá, mert az 5 másodperces bootot ugyanezekkel a patchset-ekkel (is) érték el. Mellesleg Linux októberben visszadobta ezeket a patcheket, úgyhogy nem valószínű hogy most majd diadalmenetben fog bevonulni ez a patchset a mainline kernelbe...
---
;-(

"Mellesleg Linux októberben visszadobta ezeket a patcheket,"

Azok _nem teljesen_ ezek a patchek voltak:

This patch series is based on Linus' original reaction to some of the
fastboot patches which introduced an "asynchronous initcall level".
Linus did not like the initcall level approach much, and wanted a much
more finegrained kind of thing.

This patch series introduces asynchronous function calls.
The goal is still the same (boot faster), the method is entirely
different
.

Fastboot revisited: Asynchronous function calls

--
trey @ gépház

en is ki be kapcsolgatom a laptomom, s2ram nal gyorsabb ugyse lesz.
2 sec es fut a kde4/firefox/ooo3/gimp.

persze vmi kritikus servenel, ha esetleg rebootolni kell, pl kernel upgrade eseten latom hasznant. persz az ilyen szerverek 5 percet szorakoznak mire a GRUB/LILO szohoz jut. itt aztan meg az 5-10 sec ide vagy oda, nem oszt.

jól hangzik, bár a tuxonice óta nem nagyon izgat a bootolás ideje

C64-esem még így is gyorsabban bootol :D

OT
Sajnos a telefonom (ami persze nem Linuxot futtat) már most is lassabban bootol - sőt a login (PIN-kód bekérése) is majdnem olyan lassú, mint az asztali gépemé.

Sziasztok!

Én pár éve mikor elkezdtem linuxot használgatni, akkor azért választottam sokszor inkább az xp-t a grubból, mert hamarabb bootol, hamarabb jutok oda, hogy megoldjam, amit szeretnék. Azóta már sokat javult a helyzet, de egyálatlán nem zavarna, ha javulna a linuxos bootolás sebessége. Az átlag felhasználó is elvárása is az - amiért egyáltalán ezen a projekten elkezdtek dolgozni, ha jól sejtem -, hogy minél hamarabb szóljon a zene, menjem a film stb....
Nem sértés képpen, de nem mindenki úgy tölti a napját, hogy minden művelet (meló) között főz egy kávét, iszik egy teát, vagy megeszik egy boci csokit. Ha éppen igen sürgető lenne valami, olyankor elég idegfeszítő fél/egy percet várni.

A s2ram-ot én is használnám, de a régi "ócska" gépemen nem sikerült elérnem, hogy müködjön...

(Abit nf7s 2.0, Nvidia 6600GT)

"Nem sértés képpen, de nem mindenki úgy tölti a napját, hogy minden művelet (meló) között főz egy kávét, iszik egy teát, vagy megeszik egy boci csokit. Ha éppen igen sürgető lenne valami, olyankor elég idegfeszítő fél/egy percet várni."

Ez így van. Ezekre találták ki az instant-on Linux-okat, amelyek a korszerű alaplapokba már be vannak "építve".

--
trey @ gépház

Egyet ertek azzal, hogy ugyse rebootol sokat az ember.
De szerintem egy normalis rendszernek asyncron modon kellene bootolnia.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.