'Nieuwe Linux-kernels gebruiken meer energie'

Niet alleen Linux-kernel 2.6.37 zou een aanzienlijk hoger stroomverbruik kennen dan oudere Linux-kernels, in kernelversies 2.6.38 en 2.6.39 is een nieuwe, nog niet opgeloste bug gevonden. Hierdoor neemt het energiegebruik nog verder toe.

Dat stelt website Phoronix op basis van metingen van het energiegebruik van een aantal Ubuntu-releases die deze kernelversies gebruiken. Vorige week doken al berichten op dat kernelversie 2.6.37 een hoger stroomverbruik kent dan oudere kernels. Afhankelijk van de gebruikte hardware zou het verbruik 10 to 30 procent hoger liggen. Dit is vooral nadelig voor notebookgebruikers die het uithoudingsvermogen van de accu zien verminderen.

Inmiddels heeft Phoronix aanvullende benchmarks losgelaten op kernelversie 2.6.38 en de nog in ontwikkeling zijnde versie 2.6.39. Hieruit zou blijken dat deze kernels nog meer stroom verbruiken, gemiddeld 6 procent meer. Op een testlaptop, een ThinkPad R52, lag het stroomverbruik met kernels ouder dan 2.6.35 nog op gemiddeld 21 à 22W, terwijl het verbruik met kernel 2.6.35 steeg naar gemiddeld 25W. Kernel 2.6.38 komt uit op een gemiddeld verbruik van 26W.

De precieze oorzaak van het gestegen energiegebruik van recente Linux-kernels is niet duidelijk, maar wijzigingen in het geheugenbeheer zouden een oorzaak kunnen zijn. Desondanks zijn er diverse Linux-distributies die de energiehongerige kernelcode gebruiken. Zo zal kernelversie 2.6.38 onder andere worden toegepast in Ubuntu 11.04, dat deze week moet uitkomen.

Reacties (103)

Op launchpad staat dit ook als bug vermeld onder high importance om te fixen en zal waarschijnlijk via standaard updates gepatched worden.

Kan iemand mij uitleggen hoe software kan zorgen voor een hogere energierekening? Ik snap dat de software ervoor kan zorgen dat alles harder werkt, maar dat lijkt me wel erg vreemd op deze manier.

In het artikel wordt al genoemd dat het mogelijk een probleem in het geheugenbeheer zit. Een kernel stuurt het geheugen heel erg low-level aan. RAM houd haar inhoud vast zolang er spanning op staat, als de kernel (zei het foutief) het RAM onnodig bezet houd of niet vrijgeeft als het niet meer nodig is, dan heb je bijvoorbeeld al meer vermogen verbruik. Andersom kan ook: dat de kernel heel erg strict is in weggooien en terug inlezen in het geheugen, waardoor de harddisk overuren draait en het geheugen een hoop "onnodige" lees/schrijfacties uitvoert. En daartussen zit weer de CPU die als onderhandelaar dient.

Zoveel manieren waarop software je accu kan leegtrekken, een kernel die het geheugen verkeerd benadert of een "bug" heeft (kan zelfs een memory leak zijn) is wel héél dicht bij de basis!

Dat klinkt best wel raar. RAM houdt inhoud idd vast met/door stroom. Maar of deze nou vol zit of niet, er moet toch stroom doorheen gaan.

Oftewel, als 1 4GB reepje slechts voor 1GB gevuld is, zal deze toch niet minder verbruiken dan wanneer 4GB gevuld is.

Als het verbruik van een kernel hoger is, dan zal ik meer denken aan dat ie een actie met 100% cpu power laat afvuren ipv dat ie misschien 10% nodig heeft en niet zozeer hoeveel geheugen die gebruikt.

Maar het vullen van de RAM zal dan toch wel meer verbruiken? 1GB vullen duurt langer dan 4GB vullen lijkt mij... Elke keer dat je RAM gevuld moeten worden zal je CPU weer moeten gaan werken (volgens mij)

Hut VULLEN en LEZEN zal idd wel meer moeten verbruiken. Maar het in stand houden niet. En dat is dus wat umbrah zegt

het RAM onnodig bezet houd of niet vrijgeeft als het niet meer nodig is, dan heb je bijvoorbeeld al meer vermogen verbruik.

(doet me denken aan een geintje. Dat een gevulde HDD zwaarder is dan een lege )

Nah, het maakt niet véél uit, maar wel een beetje. Ik doelde inderdaad op die acties. Overigens: slimme controllers kunnen wel degelijk selectief zijn in wat ze laten refreshen en wat niet; er zit wel degelijk een soort "defragmentatie" in RAM waardoor de sectoren wat slimmer neergezet worden: stel dat ik 4 rijen heb elk met 4 gigabyte geheugen; dan zal ik dus 16 gigabyte hebben. Zolang ik onder de 8 gigabyte gebruik zit zal de controller twee DIMM's eigenlijk niet eens poweren en het ook nog eens "slim" genoeg doen dat ik optimaal dual channel gebruik.

Maar inderdaad: zodra een chip in gebruik is, is vasthouden niet eens zo duur, het veranderen echter wel. En een rotte kernel zou het veranderen vaak doen terwijl vasthouden misschien slimmer was. Garbage Collect blijft een lastig concept, sommige smartphone platforms hadden dat tot voor kort nog 100% handmatig aan de programmeur over gelaten, tegenwoordig kan de compiler al wat meer.

Ik denk dat Linux "by design" gewoon wat complexer is hierin vanwege het monolithische ontwerp.

Elk modern OS je RAM zo vol mogelijk proppen met data die het misschien nodig zal hebben (aka disk/page cache). Optimalisaties met defragmentatie zoals jij het noemt lijken me dus absoluut zinloos.
Daarnaast gaat het hier echt niet over meer of minder memory accesses, maar over de code die het geheugenmanagement doet. Als daar meer CPU cycles aan gespendeerd worden dan heb je een hoger verbruik.
Trouwens doet Linux helemaal geen garbage collection op memory. Garbage collection zoals jij het bedoelt is op een veel hoger niveau geregeld (in de run-time van je taal, zoals de dalvik of java VM).

Linux is monolithisch in die zin dat je 1 grote kernel bouwt (tov micro-kernels) maar under the hood is de linux kernel enorm modulair opgebouwd.

het onnodig in stand houden niet, maar het onnodig weggooien, wel, het veranderen van fase voor een bit (van 1 naar 0 of omgekeerd) kost mee strom dan het instand houden van die waarde, - en bovendien, als je onterecht verkeerde gegevens in het geheuge houd, betekend het op den duur dat je gaat swappen, en laat dat swappen dan nu weer net meer strom kosten.

Maar het in stand houden niet

Toch kan dat wel meer kosten, als de kernel een onnodig hoge refresh frequentie heeft ingesteld voor de memories...

Of heel simpel; Stel je hebt een loopje dat iets checkt ("ben ik al klaar?" of "is mijn resultaat er al?"). Stel dat dit loopje te kort wacht tussen de checks. Dan kost het checken onnodig veel energie, maar is daarmee de responsiviteit van het systeem wel hoger. Dat is dan een afweging waarbij hoge responsiviteit niet altijd zinvol is.

Soms echter gaat het om een bug; stel dat die check ingebouwd zit in een process wat deze check zelfs uitvoert als het process niet hoeft te verwachten dat de check zal slagen. Voorbeeld; Een GUI die input afhandelt terwijl de gebruiker de GUI niet te zien krijgt omdat hij in een ander programma bezig is.

Ik heb soortgelijke effecten al vaak genoeg gezien. Het vervelendste voorbeeld is een app die je vergeet uit te zetten en je door de multitasking uit het zicht verliest. Een uur later is dan de batterij van je mobiele device ineens leeg

Als Linux zo zou zijn geschreven, zouden de prestaties nooit in de buurt komen van wat ze nu zijn. Over het algemeen werkt zo iets meer als 'laat maar weten als er iets verandert in de situatie, ik wacht wel'. Daarmee is ook de responsiveness het hoogst.

Input werkt ook over het algemeen zo, en hoewel ik niet intiem ben met de implementatiedetails van X, gok ik dat het ongeveer werkt zoals Windows doet; met messages. De meeste Windowsprogramma's doen, als jij niks doet, helemaal niks (ook niet in een loepje) maar wachten tot je wat doet of het systeem wat te melden heeft.

Klopt uiteraard (die 'messages' waar je het over hebt noemt men interrupts). Bij bepaalde stukken code kan men echter niet werken met interrupts noch door het process uit de running queue te halen. Bijvoorbeeld in interrupt afhandeling zelf. Zulke spinlocks worden uiteraard fel vermeden in iedere kernel daar ze de CPU 100% bezighouden tijdens het wachten. Ik denk nu niet dat de regressie van een spinlock komt aangezien Linux's kernel developers meestal wel een vrij goed zicht hebben op welke spinlocks er bestaan (dus die zullen ze al wel nagekeken hebben).

Je kan het vergelijken als je fiets met een lekke band. Je bereikt hetzelfde van A naar B maar met veel meer weerstand. Of misschien beter. Als er een trein uitvalt moet je via een omweg (Via C en D) naar B. Als er een software bug/whatever ergens tussen zit zodat het niet meer optimaal presteert moet de processor dus wat extra zijn best doen.

Of als je geheugen volzit gaat ie de hd gebruiken (weet niet hoe het met telefoons werkt) en dan wordt de hd weer meer gebruikt dan nodig.

[Reactie gewijzigd door mokkol op 26 april 2011 10:05]

Meer recources dus, jammer (denk ik). Laat Linux nu zien dat Windows eigelijk voor liep op het gebruik van system resources management en ze nu volgen of blijft er een significant verschil denk niet dat google me dit al kan vertellen

waar heb jij het nu weer over?

misschien je vraag / of opmerking wat duidelijker maken,

wat heeft windows met het afkalven van de linux broncode te maken,
er zitten gewoon essentiele problemen in de code van een stukje software waardoor het niet meer zo efficient met resources om lijkt te gaan als voorheen.

Umbrah heeft het over een discussie tussen Tanenbaum en Torvalds, die ooit in 1992 (ofzo) begon, die gaat over de vergelijking tussen de linux en minix kernel. Hier wat info.

Waarom Umbrah vindt dat Microsoft en Apple hebben gekozen voor een hybride oplossing begrijp ik nog niet helemaal... Zowel de linux en minix kernel draaien op veel verschillende hardware-architecturen, waar Microsoft zich beperkt tot X86 en Itanium(?) en Apple alleen de eigen hardware ondersteunt. Ik zou dat niet 'hybride' durven noemen tbh.

Verder zijn twee commerciele bedrijven (Microsoft, Apple) vanuit hun perspectief altijd een lachende derde. Ze verdienen er namelijk een goede boterham mee. De hele linux community (lees: ontwikkelaars) hebben een heel ander doel, dus ook die vergelijking klinkt mij nogal krom in de oren

Linux is een monolitische kernel, Tanenbaum was een groot voorstander van microkernels. Windows en OS X gebruiken een hybride kernel structuur, in feite een compromis tussen die twee uitersten.

die vergelijking was voor mij wel wat ver gezocht, / een ´linkje´ had iig een hoop gemakkelijekr gemaakt.

Ik denk dat in alles van de magical kernel patch, tot mobile devices en zelfs deze bug het eeuwige Tanenbaum/Torvalds verhaal naar voren komt.

En de lachende derden Microsoft en Apple die beide voor een meer hybride oplossing gekozen hebben.

Een vergelijking met een auto lijkt me beter. Je kan van den haag naar amsterdam rijden in z'n 5. Lekker zuinig. Maar je kan in dezelfde tijd de afstand ook afleggen in z'n 4. Totaal onnodig, maakt lawaai, verbruikt meer. Maar het eindresultaat blijft hetzelfde.

Precies zoals je zegt. Als de software kan zorgen dat alles harder werkt, stijgt het stroomverbruik. Neem bijvoorbeeld een processor: hoe harder deze werkt, hoe hoger het verbruik en hoe meer hitte er gegenereerd wordt. Als de kernel er dus voor kan zorgen dat de processor niet automatisch terugklokt in idle, staat hij ook op volle kracht te draaien als het niet nodig is, dus wordt er meer stroom verbruikt dan nodig is.

Edit: ik weet niet zeker of een kernel werkelijk verantwoordelijk kan zijn voor het automatisch terugklokken van een cpu, maar in deze richting (cpu, ram, hdd etc.) moeten we het antwoord volgens mij wel zoeken.

[Reactie gewijzigd door ronald89 op 26 april 2011 10:00]

ik weet niet zeker of een kernel werkelijk verantwoordelijk kan zijn voor het automatisch terugklokken van een cpu

Zeker wel, als de kernel ieder keer dat de CPU wil terugklokken (wat meestal gebruikt als de processor even in idle mode staat) de CPU weer 'wakker' maakt, zal die nooit terugklokken. En dat is maar één van de vele voorbeelden waarop het fout kan gaan.

Het is net zoals een auto. Hoe harder je rijdt, hoe meer benzine je verbruikt. Als je software meer vraagt van je systeem (lees processor, geheugen, harddisk gebruik), dan kost dit meer energie.

Door minder efficient werken. Of door bijvoorbeeld processen op de achtergrond te laten draaien. Dit kunnen meerdere dingen zijn. Maar het komt er op neer dat er dan meer resources gebruikt worden.

En wat denken we van datacenters, waar enorm veel stroom wordt verbruikt?
Daar is het niet zo boeiend of machine X nou 10% meer of minder verbruikt, maar het gaat hier om duizenden kilowatts en hele 'straten' met racks.
10% meer of minder zet dan echt wel zoden aan de dijk.

Als mensen nu servers op gaan hangen met distro's die die nieuwe kernels gebruiken loop je ook het risico dat die kernels nog (erg) lang in gebruik zijn (je komt soms nog 2.4 kernels of ouder tegen in DCs).

Ik hoop, dat een beetje datacenter zijn eigen kernel samenstelt/build en alle overbodige meuk eruit flikkert. Ik deed dat standaard met Red Hat, totdat de (White Box) builds dermate slecht werden, dat ze geen kernel build out-of-the-box meer ondersteunden.

Het scheelt enorm aan omvang van je kernel, plus je krijgt een veiliger kernel. Hoe minder randapparatuur je standaard ondersteunt, hoe minder kans je hebt op een lek, en dus: exploit. Of -zoals het hier lijkt- bug

Daar wordt het inderdaad serieuzer. Gelukkig denk ik dat geen enkel serieus datacenter met met heel recente versies van Linux (of wat voor software dan ook) zal draaien...
He lijkt me dat ze daar alleen met bewezen betrouwbare software werken...en het duurt gewoon even voordat een nieuwe versie zich zelf heeft bewezen.

Ik neem aan dat systeembeheerders voor de LTS release van ubuntu gaan wegens de obvious reden dat de support beter is. 11.04 is dan ook geen LTS release en bovendien lijkt het mij dat systeembeheerders wel eens het systeem updaten waarmee dit hopelijk gefixed wordt.

Phoronix heeft de test gedaan op welgeteld één laptop. Het is gewoon onzin om hieruit te besluiten dat de Linuxkernel op elke machine 10% meer verbruikt: de bug kan gewoon in één specifieke driver zitten die door die laptop gebruikt worden. Ik twijfel er niet aan dat er ondere andere besturingssystemen ook wel bepaalde driverversies zullen bestaan die onefficiënt geschreven zijn en daardoor het energieverbruik meer doen toenemen dan nodig.

Dus ja, er is weldegelijk ergens een bug/regressie die moet opgelost worden, maar de algemene conclusie dat nieuwere kernels meer energie verbruiken, is op basis van deze test nog altijd ongefundeerd en onbewezen.

Misschien is het handig om even op phoronix rond te kijken in de artikelen en misschien was je bijvoorbeeld deze tegengekomen, artikel van 3 dagen geleden. Hier test phoronix 4 verschillende laptops met ati, nvidia en intel graka's, verscheidene processoren en een totaal van 7 verschillende versies van ubuntu. Heel raar maar alle systemen hebben een stijging in het verbruik sinds de nieuwe kernel.

edit: overigens snap ik niet waarom tweakers dit niet vermeld in het artikel

[Reactie gewijzigd door rockmanz op 26 april 2011 10:20]

Het probleem met Phoronix is dat hij nogal lukraak test. Hij pakt een paar laptops, gooit een nieuwere Ubuntu erop, en concludeert dat dat de kernel meer energie vraagt.

Hallo?

Enig idee hoeveel meer is er veranderd in Ubuntu 10.10 -> 11.04?
Dit is geen test van Ubuntu 10.10 met een nieuwe kernel, maar het totaalpakket, en met zoveel variatie in de tests dat "volgens hem" het toch echt aan de kernel moet liggen. Dat er misschien ook een nieuw init-systeem is, nieuwe GNOME versie of networkmanager laat hij hierbij links liggen. Ook al ligt het misschien aan de kernel, is hiermee niets echt bewezen.

Dit is de Maurice de Hond van de performance statistieken, en je kunt die beter negeren.

[Reactie gewijzigd door YaPP op 27 april 2011 10:23]

Daarkomt nog bij dat ze een ubuntu kernel hebben gebruikt (waar ubuntu ook nog wat aan tweakt). Als Phoronix de linux kernel test dan moeten ze ook De Linux Kernel testen en niet een binairy van ubuntu op hun laptop kwakken.

Ik dacht dat het artikel het had over de kernel en voor zover mijn kennis gaat heeft die niks met drivers te maken.

@rockmanz: Thanks.

[Reactie gewijzigd door bertjoe op 26 april 2011 12:11]

Zie deze wiki waar de volgende quote vandaan komt: "In Linux environments, programmers can build device drivers either as parts of the kernel or separately as loadable modules. "

Geldt dit ook niet voor Android gebruikers dan? Ben niet zo heel diep meer thuis in Linux en weet niet precies welke kernel er in Android gebruikt wordt.

Bij Android wordt er gebruik gemaakt van de ARM-processor, deze testen gaan over de x86-versie van de Linux kernel - iets met appels en peren?

Verder kan men gewoon kiezen om bij Android het oude geheugenbeheer te gebruiken (kan wel vervelend patchwerk worden overigens) of inderdaad op de oude kernel blijven hangen...

Bij Android wordt er gebruik gemaakt van de ARM-processor, deze testen gaan over de x86-versie van de Linux kernel - iets met appels en peren?

Dat hoeft niet per definitie een verschil te maken...

Hoeft inderdaad geen verschil te maken, maar ik moet zeggen dat ik er op m'n netbook nix van gemerkt heb kwa batterij duur (kernel 2.6.38). 'T zou best kunnen dat de bug alleen intel core CPU's treft.

maar ik moet zeggen dat ik er op m'n netbook nix van gemerkt heb kwa batterij duur (kernel 2.6.38).

Heb je exacte meet gegevens of is dit slecht 'een gevoel'.
Het lijkt me namelijk niet zo voor de hand liggen dan je bijvoorbeeld een drop van bijvoorbeeld 5% in performance spontaan opmerkt

Als ik lees dat mensen die last hebben van de bug hun accu duur zien terug lopen van b.v. 4 naar 2½ uur (wederom intel core laptops, toevallig?). Dan heb ik daar geen last van. Natuurlijk varieert het nogal hoelang ik met m'n accu doe, afhankelijk van waar ik m'n netbook voor gebruikt heb en een kwartiertje minder zal niet op vallen. Meer naar beneden staat ook een post van iemand met een AMD laptop (?) die ook nix gemerkt heeft.

En verder naar beneden staat weer dat deze testen ook gedaan zijn met AMD opstellingen
Dit soort problemen blijven altijd vaag en zullen niet op iedereen hetzelfde effect hebben naar mijn mening

Ik heb zelf een laptop met een intel CPU en kernel 2.6.35-28 en merk niet echt wat van korte accu-duur

Ruim 3 uur met programmeer-tools (waaronder een emulator) draaiende

Heeft Android ook niet een uitgeklede aangepaste kernel? SCSI, SATA, Geforce etc, is allemaal niet nodig en kan er dus uit.

Dat zijn meestal toch modules die aan de kernel zijn gehaakt?

Daarnaast leuk nieuws bericht maar hoe staat het in verhouding tot windows phones en IOS eigenlijk (IOS is standaard hardware dus is een beetje krom, maar toch!)


Overigens een tip:

Er zijn instructies te vinden om voor linux systemen 3/4 snelheidswinst te boeken vooral met SSD/flashgeheugen dit heeft te maken met het loggen van Linux (ze loggen nogal veel standaard!) (mocht er iets fout gaan kun je het natuurlijk moeilijker/niet terug vinden maar toch!)

[Reactie gewijzigd door rob12424 op 26 april 2011 20:08]

Kan je aangeven waar ik dan op moet zoeken?
Ben altijd wel geinteresseerd om dat te proberen (als het natuurlijk ook werkt voor Android phones )

Nee, Linux distributies (waar Android dus een van is) updaten niet meteen zodra de kernel update. Hij zal er nog wel niet in zitten, en dan nog: Android telefoons worden toch nooit geupdate.

Daarnaast hoeft de bug niet ook in het ARM gedeelte te zitten.

[Reactie gewijzigd door Wolfos op 26 april 2011 09:55]

Ik weet wel dat in custom ROMs custom kernels zitten welke door modders dan geüpdate zouden kunnen zijn. Er zijn een aantal custom ROMs waarbij er onverklaarbare battery drain plaats vindt, zodoende dat ik hieraan dacht. Dit geld in ieder geval voor de Galaxy S custom ROMs.

Android telefoons worden standaard geupdatet als mensen een nieuwe telefoon kopen. Dat de meeste mensen na aankoop niet meer de moeite nemen om updates te installeren betekent niet dat niemand hier last van krijgt. Mocht er ooit een android versie uitkomen waarin deze kernel verwerkt is dan zullen veel mensen onnodig snel de accu leeg hebben.

Ik denk niet dat Google een Android versie maakt met deze bug erin. Daarnaast weten we nog steeds niet of de bug ook in de ARM versie zit.

Tenzij ze het al gedaan hebben, aangezien deze bug nu pas bekend wordt.
Daarnaast, zoals al eerder vermeld, de meeste mensen die hun firmware updaten maken waarschijnlijk gebruik van custom roms. Dus dan zal het sowieso wel weggepatchd worden zodra de fix bekend is.

Nu is powermanagement al jaren een doorn in het oog voor linux kernels en waren ze hard op weg om alle fratsen en implementaties te supporten.

Jammer dat ze de laatste kwartalen nu opeens weer elders meer energie nodig hebben. Tevens frappant dat dit via Phoronix naar buiten komt. Hebben er toch een paar zitten slapen bij het inchecken van hun wijzigingen denk ik zo.

@Joshua:
De wonderpatch zou theoretisch een paar cycles extra gebruiken idd om evenredig proberen de rekenkracht te verdelen over verschillende processen ipv dat 1 process omgeving op z'n gat zou trekken. Of dit daadwerkelijk zo heavy is dat het 10 / 30% scheelt is een tweede, maar bijdragen kan altijd.

Het is niet dat iemand zit te slapen. Er moeten nu eenmaal changes aangebracht worden voor verschillende redenenen. Dat daarbij niet altijd naar battery lifetime gekeken wordt is normaal. Het is aan testers om dat soort dingen op te merken, je kan niet verwachten dat elke kernel hacker de beschikking heeft over tal van machines.

OK, de kernel is onzuiniger. Maar in het geheel? en ten opzichte van de os-concurrenten?

Op een testlaptop, een ThinkPad R52, lag het stroomverbruik met kernels ouder dan 2.6.35 nog op gemiddeld 21 à 22W, terwijl het verbruik met kernel 2.6.35 steeg naar gemiddeld 25W. Kernel 2.6.38 komt uit op een gemiddeld verbruik van 26W.

Dat zegt voldoende over het geheel, in ieder geval voor deze steekproef.

De < 2.6.30 kernels komen er in de grafiekjes het zuinigst vanaf, maar in een oogopslag heb ik niet gezien of er nog rekening gehouden wordt met de prestaties die er tegenover staan.

Vergelijkingen met andere besturingssystemen staan er in deze test niet bij.

Dat is het omgekeerde van de ervaring die een aantal tweakers die goed bekend zijn met linux hebben. Linux en zuinigheid is een mijnenveld, maar als je het goed doet kun je op net zulke goede waarden uitkomen als Windows 7 (die i.h.a. de zuinigste resultaten neerzet).

En wat met de prestaties?

Hoger verbruik is prima als je ook merkbaar sneller taken kan afhandelen.

Op mijn amd e350 merk ik hier niets van om eerlijk te zijn, ik gebruik de laatste beta van ubuntu 11.04 (met proposed updates).