Tickless: szakember a Linux kernel új energiatakarékossági szolgáltatásáról

Kernel

Arjan van de Ven, az Intel kernelhackere, aki aktívan közreműködik a PowerTOP utility körüli munkákban, egy szakmai cikkben mutatja be a Linux kernel "tickless idle" vagy egyszerűen csak "tickless" funkcióját, amely elősegíti a hatékonyabb energiafelhasználást. Az érdekes cikk (regisztráció után) itt olvasható.

( uid_14357 | 2007. 08. 11., szo – 13:20 )

[Kicsit OFF]
Nah ezt nem szoktam szeretni, amikor egy "mezei" cikk elolvasásához is regisztrációval kell szenvedni. Mi értelme van egyáltalán?
szerk: arról nem beszélve, hogy a regisztrációs form maga 3 oldal és 90%-át kötelező kitölteni.

( ProTech | 2007. 08. 11., szo – 13:52 )

Hasznal valaki tickless kernelt laptopon? Menyire megbizhato, vannak-e vele problemak? Most tervezek egy uj 2.6.22-es kernel forgatast, es gondolkozok rajta, hogy bekapcsoljam.

Hm én Turion X2-es laptopon használom, és a fogyasztásom átlag 16-17 Watt aksiról (kijelző fényerő 60%-on), ami olyan 3,5-4 óra üzemidőt jelent, filmnézésnél ~3 óra.
Csináld meg a powertop-ban megjelenő tippeket és kész is :)
Nem nagyon kavar be semmibe, nyugodtan engedélyezd.
Mivel intel procikra íródott a powertop, lehet azokkal nagyobb energiamennyiséget lehet megspórolni.

Centrino Duo-val sikerült átlagos CPU használat mellett 2 W-os fogyasztásról 1,4 W-ra levinni, viszont a powertop-ban még mutatkozik néhány elég magas megszakításszámú process, ami részben bug (knotify, hald) illetve hardvertervezési hiba (hda-intel) miatt van, de igy is majdnem negyed órával sikerült hosszabb akkuidőt elérni 100-300 as megszakításszámmal másodpercenként. Xfce-vel ez 50-200 1,2-1,3 W. Ez Windowszal,amikor gyárilag még volt rajta 2 óra 20 percig sem bírta az akksi, igaz Home Edition, Slackware 11 régi kernel (~2.16.*-tól) KDE majdnem 3 óra Xfce4.4-gyel 3 óra 10 perc. Az 1 éves 98%-os akksival, thickless kernellel 2.6.22.1 3 óra 15 perc KDE-vel, Xfce 4.4.1-vel meg még nem merítettem le soha, de az ACPI 2 óra 30 percet írt még 1 órás használat után.

Szóval tapasztalataim szerint mindenképpen érdemes.

Üdv!
___________________________________________________
Slackware 12 - linux-2.6.22.1-smp - KDE 3.5.7

( pinyo_villany | 2007. 08. 11., szo – 15:09 )

[off]
"In the Linux kernel, the driver for the HPET is in drivers/char/hpet.c, with an architecture specific portion in arch/i397/kernel/hpet.c."
ezt kicsit elirták, én spec ilyenről nem tudok, csak i386-os arch van a kernelben
[/off]

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

( uid_228 | 2007. 08. 11., szo – 18:45 )

"While these power consumption numbers denote the maximum possible (or 'TDP') values..."

Höhö. Azért nem kéne ilyen finoman csúsztatni. Az Intel pont, hogy nem a legnagyobb fogyasztást adja meg a TDP-nél.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( asch v | 2007. 08. 13., h – 10:13 )

Tehát a userspace programok között a trükk az, hogy az "időnként meg kell csinálni" feladatokra nem "sima" időzítőt indítunk, ami akármikor felkelthet, hanem másodperc határra igazítottat.

Mivel én többnyire Javát programozok felmerül a kérdésem, hogy Javában ezt hogy kellene elérni? Ameddig nem lesz Java API hozzá, addig workaroundként megfelel, ha a System.currentTimeMillis szerinti másodperc elejére próbálom tenni a sleep-ek felébredésének időpontját?

Másik kérdésem, hogy nem olyannak kellene lenni az API-nak inkább, hogy azt mondhatja a programozó, hogy 2 és 3 másodperc között valamikor akarok felkelni? Így a hívás kicsit általánosabbnak tűnik, mint konkrétan másodperc elejére kérni. Frankón skálázható bármerre. Mindig intervallumot adunk és az ütemező a saját szempontjai szerint eldöntheti, hogy hova teszi pontosan, viszont nem veszítjük el a külső szabályzás lehetőségét akkor sem, ha történetesen csak fél másodpercünk van várni.

> workaroundként megfelel, ha a System.currentTimeMillis szerinti másodperc elejére próbálom tenni a sleep-ek felébredésének időpontját?

Nem szerencsés, ha egyazon időponthoz túl sok szereplő szinkronizálódhat. Én a kerekítés után hozzáadnék az időpontokhoz egy-egy konstanst. (sleep()-enként különböző, <1mp konstanst.)

> nem olyannak kellene lenni az API-nak inkább, hogy azt mondhatja a programozó, hogy 2 és 3 másodperc között valamikor akarok felkelni?

Ez már real-time igény. "Normál" OS akkor adja át a vezérlést, amikor "kényelmes", nem pedig akkor, amikorra kérték.

Amikor azt mondja a programozó, hogy 2 másodperc múlva akarok felkelni, akkor csak annyi a biztos, hogy 2 másodpercnél hamarabb nem fog felkelni a program. De az is lehet, hogy még egy perc múlva se ...