'Nieuwe Linux-kernels gebruiken meer energie'

Reacties

« 1 2 3 »

Door ericcgg, dinsdag 26 april 2011 09:52

Door Mellow Jack, dinsdag 26 april 2011 09:54

Mijn Android gebruikt volgens mij 2.6.32.35 dus ja beetje wannabe first post ideetje

Door Godjira, dinsdag 26 april 2011 09:57

Dat ligt helemaal aan de ROM die je op je telefoon hebt natuurlijk. Er zijn genoeg custom ROMS die al gebruik maken van de kernel 2.6.38. Zelf draai ik GingerVillain op mijn HTC Desire, maar ik merk daaraan niet dat deze sneller leeg loopt.

Door Mellow Jack, dinsdag 26 april 2011 10:03

Klopt maar het is exact zoals jij het zegt

de custom ROMS hebben mogelijk een nieuwe kernel maar tot nu toe is dr volgens mij nog geen stock telefoon met een hogere kernal dan 2.6.36. Naar mijn weten natuurlijk, ik ben nog niet op de hoogte van bijv die Speed 2x telefoon (LG?)

Door Supremo, dinsdag 26 april 2011 10:52

Heb laatst versie V10b op mijn LG 2X gezet en die zegt nu kernel 2.6.32.9. De LG 2X heeft nu dus een patch gehad op Froyo en met een beetje mazzel hebben we over een maand de upgrade naar Gingerbread.

Door svenk91, dinsdag 26 april 2011 11:04

Op de xperia play word dezelfde kernel gebruikt (stock gingerbread 2.3.2).

Door bl0m5t3r, dinsdag 26 april 2011 14:50

daar ben ik het niet mee eens, ik merk weldegelijk dat sinds de laatste gingervillain releases (met kernel .37 en zeker .38) de batterij in standby sneller leegloopt.. ook als ik een HAVS versie met een lager voltage install. Echter als ik de .35 kernel er weer opzet (dit alles kan allemaal heel makkelijk via het villain menu) gaat de accu weer langer mee.

ik heb het een en ander ondertussen uitvoerig getest op m'n desire, en het is echt een meetbaar verschil. Het nieuwsbericht sluit dan ook aan bij mijn eigen bevindingen.

Door kevinv2u, dinsdag 26 april 2011 10:39

Ze hebben het over notebooks in het artikel maar op zich maak je natuurlijk een goed punt. Tegenwoordig draaien ook veel smartphones op een Linux kernel en daarvoor is het hogere energieverbruik nog nadeliger.

Door worldcitizen, dinsdag 26 april 2011 11:06

Tegenwoordig draaien ook veel smartphones op een Linux kernel en daarvoor is het hogere energieverbruik nog nadeliger.

Klopt en dit heeft direct ook weer een voordeel. Omdat dit in een smartphone erg belangrijk is. Zal dit sneller opgelost worden.
In een smartphone zul je geen kernel gebruiken die 6% meer vermogen verbruiken.

Door BeosBeing, dinsdag 26 april 2011 11:51

Dus Android zal deze kernels niet gebruiken of Google zal er zelf een een oplossing voor bedenken.

Bij de ontwikkeling van de Linux-kernel wordt er nu vooral aandacht besteed aan high-end systemen, met meerdere tientallen cpu's/cores en meerdere Gb aan geheugen, ik denk dus niet dat dit een hoge prioriteit gaat krijgen.

edit: Hieronder meldt rockmanz dat de bug op launchpad staat onder high importance, dus de prioriteit zal er toch wel zijn.

[Reactie gewijzigd door BeosBeing op dinsdag 26 april 2011 11:54]

Door zakariaemrabet, dinsdag 26 april 2011 12:24

Of het een high- of low-end systeem is, maakt verder niets uit als het om energieverbruik gaat.

Door johnkeates, dinsdag 26 april 2011 15:17

Wat maakt dat nou weer uit? Als een programmeur vind dat de kernel minder stroom moet verbruiken, dan lost hij dat op, stuurt de patch naar kernel.org, daar kijken ze of het goed zit en dan komt ie er in. Het is niet een of ander bedrijfje zoals HTC of Google, maar een systeem waarbij iedereen oplossingen mag aandragen als ze dat willen. En dan wordt het ook nog eens opgenomen, en beschikbaar gesteld aan iedereen die dat maar wil.

Door Ook al Bezet, dinsdag 26 april 2011 18:18

Wat maakt dat nou weer uit? Als een programmeur vind dat de kernel minder stroom moet verbruiken, dan lost hij dat op, stuurt de patch naar kernel.org, daar kijken ze of het goed zit en dan komt ie er in. Het is niet een of ander bedrijfje zoals HTC of Google, maar een systeem waarbij iedereen oplossingen mag aandragen als ze dat willen. En dan wordt het ook nog eens opgenomen, en beschikbaar gesteld aan iedereen die dat maar wil.

Natuurlijk, maar als een google of HTC vindt dat het probleem snel opgelost moet worden kunnen ze er een heel roedel programmeurs op zetten, die zullen het met zijn allen allicht sneller oplossen dan een enkele vrijwilliger.

Door mae-t.net, dinsdag 26 april 2011 18:23

En vervolgens sturen ze, mag ik hopen, die patch ook netjes in.

Door Ook al Bezet, woensdag 27 april 2011 00:00

En vervolgens sturen ze, mag ik hopen, die patch ook netjes in.

Dat is natuurlijk wel de bedoeling ja.

Door Superstoned, dinsdag 26 april 2011 15:59

haha, een bug met high importance op launchpad. En wat betekend dat? Canonical maakt alleen kabaal, remember. Ze werken niet echt veel aan linux. Bijv, Canonical draagt nog geen 0.01% bij aan de kernel dus als het aan hen ligt is het in nog geen 10 jaar opgelost... Zelfde met GNOME en 99% van de andere projecten die ze leveren ;-)

Ze zijn wat dat betreft net als Linspire, Xandros etc.

Gelukkig is het ook een issue voor bedrijven die wel direct aan de kernel werken zoals linux bedrijven als Red Hat & Novell, gebruikers als Google en Facebook, hardware fabrikanten als Intel, AMD, ARM, Nokia, Novell, Qualcomm en software bedrijven als Oracle en zelfs Microsoft.

Dus, nu het bekend is, zal het wel worden opgelost.

En ja, het is relevant voor beide low- en high-end systems...

Door farlane, dinsdag 26 april 2011 17:57

Bij de ontwikkeling van de Linux-kernel wordt er nu vooral aandacht besteed aan high-end systemen, met meerdere tientallen cpu's/cores en meerdere Gb aan geheugen, ik denk dus niet dat dit een hoge prioriteit gaat krijgen.

Als er ergens aandacht voor is in de Linux kernel is het wel embedded systemen, die per definitie het tegenovergestelde zijn van high-end.

Door freaxje, dinsdag 26 april 2011 13:04

(Linux) powermanagement op hardware zoals telefoons is doorgaans meer finegrained uitgewerkt dan op standaard (Linux) desktop configuraties. Het kan dus zijn dat de regressie minder uitgesproken is op zo'n systeem omdat allerlei hardware componenten steeds op- en afgezet worden (of minder en meer stroom krijgen afhankelijk van de activiteit van de gebruiker).

Door theforce81, dinsdag 26 april 2011 09:52

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.

Door Wolfos, dinsdag 26 april 2011 09:54

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 dinsdag 26 april 2011 09:55]

Door theforce81, dinsdag 26 april 2011 09:57

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.

Door BRAINLESS01, dinsdag 26 april 2011 09:58

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.

Door Wolfos, dinsdag 26 april 2011 10:01

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.

Door sab.loempia.com, dinsdag 26 april 2011 11:05

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.

Door Little Penguin, dinsdag 26 april 2011 09:56

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...

Door GENETX, dinsdag 26 april 2011 10:01

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...

Door mie9iel, dinsdag 26 april 2011 10:42

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.

Door hAl, dinsdag 26 april 2011 11:32

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

Door mie9iel, dinsdag 26 april 2011 12:45

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.

Door Mellow Jack, dinsdag 26 april 2011 14:23

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

Door hackerhater, dinsdag 26 april 2011 16:12

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

Door mashell, dinsdag 26 april 2011 14:32

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

Door rob12424, dinsdag 26 april 2011 20:05

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 dinsdag 26 april 2011 20:08]

Door copi, dinsdag 26 april 2011 23:26

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

)

Door rockmanz, dinsdag 26 april 2011 09:55

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

Door Robinvdh5, dinsdag 26 april 2011 09:55

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.

Door ronald89, dinsdag 26 april 2011 09:59

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 dinsdag 26 april 2011 10:00]

Door Korben, dinsdag 26 april 2011 10:56

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.

Door Marcelloz, dinsdag 26 april 2011 10:00

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 Umbrah, dinsdag 26 april 2011 10:00

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!

Door kmf, dinsdag 26 april 2011 10:16

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.

Door Mellow Jack, dinsdag 26 april 2011 10:21

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)

Door kmf, dinsdag 26 april 2011 10:23

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

)

Door Umbrah, dinsdag 26 april 2011 10:35

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.

Door H!GHGuY, dinsdag 26 april 2011 12:54

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.

Door i-chat, dinsdag 26 april 2011 10:45

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.

Door PPie, dinsdag 26 april 2011 11:04

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...

Door Werner, dinsdag 26 april 2011 10:01

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.

Door mokkol, dinsdag 26 april 2011 10:03

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 dinsdag 26 april 2011 10:05]

Door kmf, dinsdag 26 april 2011 10:22

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.

Door larsiano, dinsdag 26 april 2011 10:24

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

Door Umbrah, dinsdag 26 april 2011 10:38

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.

Door i-chat, dinsdag 26 april 2011 10:49

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.

Door EnigmA-X, dinsdag 26 april 2011 10:56

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

Door Dreamvoid, dinsdag 26 april 2011 12:32

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.

Door i-chat, dinsdag 26 april 2011 13:14

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

Door 0rbit, dinsdag 26 april 2011 10:14

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

Door Korben, dinsdag 26 april 2011 10:53

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.

Door freaxje, dinsdag 26 april 2011 13:42

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).

Door belrpr, dinsdag 26 april 2011 09:56

Ik hoop dat ze snel een oplossing vinden. Geen goede reclame.

Door arjankoole, dinsdag 26 april 2011 10:25

Ik hoop dat ze snel een oplossing vinden. Geen goede reclame.

Ik zie niet direct in hoe dit goede/slechte reclame is. Het is een bug, die is gededecteerd, en wordt dus opgelost. Einde verhaal.

windows heeft ook diverse van dit soort problemen gehad in haar lange geschiedenis. Bugs happen.

Door hAl, dinsdag 26 april 2011 11:11

Het is een bug, die is gededecteerd, en wordt dus opgelost. Einde verhaal.

Ik zie nergens in het artikel dat het een bug is. Misschien is dit veroorzaakt door een opzettelijk gekozen verandering in de manier waarop de kernel werkt.
Ik zie ook niet in het artikel dat de oorzaak gedetecteerd is.
Ik zie nergens in het artikel dat er iets wordt opgelost.
Voorlopig dus geen einde verhaal.

Door daft_dutch, dinsdag 26 april 2011 13:32

Omdat tweakers niet 100% blijft het wel een major regressie bug
Hier de Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760131

Door Boudewijn, dinsdag 26 april 2011 09:56

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).

Door Japs, dinsdag 26 april 2011 10:24

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.

Door rockmanz, dinsdag 26 april 2011 10:40

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.

Door The Van, dinsdag 26 april 2011 10:47

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

Door kmf, dinsdag 26 april 2011 10:00

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

Door wankel, dinsdag 26 april 2011 13:38

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.

Door mux, dinsdag 26 april 2011 10:02

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).

Door freggy, dinsdag 26 april 2011 10:06

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.

Door rockmanz, dinsdag 26 april 2011 10:19

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 dinsdag 26 april 2011 10:20]

Door YaPP, woensdag 27 april 2011 10:21

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 woensdag 27 april 2011 10:23]

Door bertjoe, dinsdag 26 april 2011 10:24

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 dinsdag 26 april 2011 12:11]

Door rockmanz, dinsdag 26 april 2011 10:35

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. "

Door mie9iel, dinsdag 26 april 2011 11:01

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.

Door c0d1f1ed, dinsdag 26 april 2011 10:08

En wat met de prestaties?

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

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

10:38	World of Warcraft stapt deze week over op IPv6
08:32	Sony presenteert Honeycomb-tablets - update

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

09:51 Nieuws

08:50 Productreviews

10:23 Vraag & Aanbod

25-05 Jobs

10:22 Etc.

10:28 Reacties

10:28 Forum

25-05 Gesponsorde acties

01:46 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines