Názory k článku
Nalezen první bug způsobující vyšší spotřebu v Linuxu
-
Škoda, že zprávička neobsahuje už aktualizovaný článek... přitom stačilo prokliknout Twitter, kde už nějakých šest hodin leží tenhle odkaz:
http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1
-
Lael Ophir (neregistrovaný)
Nějaký patch natvrdo zakázal PCI Express Active-State Power Management, pokud v tabulce ACPI FADT bylo psáno, že systém ASPM nepodporuje. Tím se zvýšila spotřeba o cca 10%. Zřejmě to není jediný bug.
Větší problém je ale v tom, že mezi dvěma verzemi kernelu dojde k výraznému nárůstu spotřeby, a *rok* si toho nikdo "oficiálně" nevšimne. A když už si někdo všimne, trvá dva měsíce, než si nějaký amatér nad problém sedne, a najde alespoň část příčiny problému. Takhle že se píše kvalitní SW? -
Ivan (neregistrovaný)
Ten "amater" to vyresil tak, ze dostal od Intelu nejakou 16ti procesorovou mrchu,
na ktery kompiloval ruzny kernely a v elektr. siti mel pripojenej notebook pres specialni zarizeni, ktery mu ukazovalo spotrebu. Jestli jsem to pochopil dobre tak na to neprisel analyzou kodu ale "pulenim intervalu".
Ten patch kterej to zpusobil, bohuzel resi problemy pri suspend/resume na zabugovanych biosech. Takhle to dopada, kdyz se MS zusastni vytvareni nejakyho standartu - vznikne MS only technologie. To neni jen ACPI treba i HPET. Ne ze by to na linuxu nefungovalo, clovek si ale musi poradne davat bacha co si kupuje. -
Lael Ophir (neregistrovaný)
A není na tom náhodou vidět komunitní přístup k psaní SW? MS má svoje certifikační testy, kde důkladně zjišťuje, jestli HW s jeho SW spolupracuje. Když výrobce udělá někde chybu, neprojdou mu MS testy, a certifikaci nedostane.
Kdyby Linux vyvíjela slušná komerční firma, tak by (vyjma jiných změn) zřejmě existoval certifikační program, který by zjišťoval kompatibilitu HW. Bohužel Linux nejen nemá funkční certifikační program (vyjma databází, kde Franta napíše, že mu nová síťovka doma funguje), ale ani nástroje pro hledání bugů v power managementu. Co brání mít v Linuxu zjišťovadlo nejčastějích bugů HW v oblasti power managementu? Co takovému nástroji brání v odeslání reportu do centrální DB (aby bylo možné masírovat výrobce HW), a případnému nastavení workaroundu v konfiguraci daného stroje? Už dávno mohla být vyřešená celá škála problémů, kde má Linux mizernou výdrž na baterky, neusíná, neprobouzí se ze spánku apod.
Můj názor? MS je (nejen) v power managementu tak 10-15 let napřed. -
dustin (neregistrovaný)
snip
Co brání mít v Linuxu zjišťovadlo nejčastějích bugů HW v oblasti power managementu?
/snip
A jak by takové zjišťovadlo testující mraky nejrůznějšího hardwaru v oblasti PM mělo vypadat?
Mimochodem, vůbec by mě nepřekvapilo, kdyby postup, který použil ten chlápek z phoronixu (tedy scm bisect v kombinaci s wattmetrem s automatizovatelným odečtem) v MS ještě nikdo nerealizoval. Pokud jo, určitě už na něj mají patent :)
-
Lael Ophir (neregistrovaný)
Jak by to mohlo vypadat? Pro inspiraci si nabootujte Windows 7, spusťte "powercfg -energy", a prohlédněte si výsledný report v %system32%\energy-report.html. Dozvíte se které power states systém podporuje, které drivery brání přechodu do kterého power state, varování, chyby atd. Navíc bych čekal aplikaci workaroundů (tj. změn konfigurace) v reakci na známé chyby HW.
BTW kdyby chtěl někdo napsat článek o power managementu v Linuxu, byl by to chvályhodný počin. Určitě by nejen mě zajímalo, jestli drivery poskytují interface pro device states, jestli aplikace a drivery dostávají notifikace při změně global state, jak vypadá implementace ACPI Machine Language atd.Postup, který použil ten chlápek z phoronixu, je dost divoký. Čekal bych spíš že to bude řešit někdo, kdo má dobrý přehled v power managementu obecně i v implementaci na Linuxu, a bude to řešit analýzou nějakého power management trace logu, kouknutím do vývojářské dokumentace, do kódu atd. Ne že by improvizace toho člověka byla špatná věc, spíše naopak. Ale improvizace většinou znamená, že pro danou situaci neexistuje "standardní" postup, což je špatně.
-
dustin (neregistrovaný)
Jestli jsem to dobře pochopil, byl problém na hardwarově podstatně nižší úrovni, než standardní power stavy Sx, což je to, co řeší ten powercfg. Ten by v tomto případě zřejmě nijak nepomohl. Kouknutí do dokumentace by nijak nepomohlo, když byl problém v tom, že výrobci desek právě standard nedodržovali.
-
Lael Ophir (neregistrovaný)
Powercfg není nástroj pro debugging power managementu, takže by opravdu nepomohl. Nicméně takhle nějak může vypadat nástroj pro automatické hledání známých bugů a aplikaci workarounds.
Z nástrojů MS můžete na troubleshooting použít PwrTest a log files (pwrmgmt.log, PwrProvider.log), možná s nastavením dalších log levels.Kouknutí do trace log files a dokumentace by u většiny problémů naopak pomoci mělo.
