Az idle loop javítása

OpenBSD

Bob Beck hackathon szervező és hivatalos bbq szakács beszámolójában arról olvashatunk, hogy hogyan sikerült egy RAID teljesítményt degradáló bugot úgy javítaniuk, hogy az operációs rendszer számos pontján profitáltak belőle.A hackathon hackereinek sikerült egy olyan bugot javítaniuk, amelynek következtében megszűnt a RAID tömbök olvasásának lassúsága, javulás tapasztalható az userland crypto műveletekben, érinti a ethernet drivereket, és még a notebookok akkumulátoros üzemidejére is jótékony hatással van.

A sztori itt.

( Gabucino | 2005. 05. 25., sze – 23:00 )

Vajon azt is fixaltak, hogy az osszes letezo altalam hasznalt hardver illetve
emulacios (qemu) kornyezetben le tudom fagyasztani a RAIDframe-t? :(
Komolyan kerdem... (mostanaban ugyis divik az esz nelkuli post errefele,
D-vel olvasas rulez)

--
Bérczi Gábor
/Gabu/

( Hunger | 2005. 05. 26., cs – 10:55 )

Hahajj, fekszem a padlón a röhögéstől... Ezeket az arcokat, micsoda sikersztori! :))

2 napja amikor első commit [marc.theaimsgroup.com] történt, akkor nézegettem is gyanúsan, hogy mit matatnak már megint a locoreban. Aztán megláttam többek között [www.openbsd.org] ezt a módosítást:

+ cmpl $0,_C_LABEL(whichqs)

+ jnz _C_LABEL(idle_exit)

jmp _C_LABEL(idle_loop)

ENTRY(idle_exit)

... és fogtam a fejem, hogy Jééézusom, mit művelnek ezek már megint! Szerencsére alig 11 órával később az egyik fejlesztőnek is szemet szúrt, hogy ez egy kicsit gázos és lecserélte [www.openbsd.org] a jnz+jmp párost egy jz-re. Hohóó, optimalizáció! "the idle loop will be even more efficient". Éljen! ;)

Az igazi poén persze nem ez, hanem az a brainstorming, amit a csapat csinált. Első körben ilyen ötlet, hogy a kernel figyeljen egy userlandben lévő processzt, hogy fut-e ("Call it only if apmd is active!") ? Anyám borogass... És ezt még le is írja ország-világ előtt. Micsoda szerencse, hogy Theo ezt nem engedte...

Ezzel 15 MB/sec-ről 105 MB/sec-re ugrott a sebesség, ejha! 15 MB/sec-nél nem volt feltünő eddig, hogy valami nincs rendben? :)