Linus er målløs: Patch på 233 linjer gør Linux-kernen til en fartdjævel

19. november 2010 kl. 08:1222
En ny patch til Linux-kernen sætter turbo på desktop-ydelsen. Linus Torvalds kalder patch'en en kæmpe forbedring.
Artiklen er ældre end 30 dage

Linux har længe været kendt som et hurtigt styresystem til servere og supercomputere, men ryet har ikke været det samme på almindelige pc'er.

Det kan dog være på vej til at ændre sig. Kerneudvikleren Mike Galbraith har nemlig skrevet en patch til Linux-kernen på 233 linjer, der populært fortalt sørger for, at browseren og videoafspilleren stadig kører som smurt, selv når CPU'en arbejder på højtryk.

Mike Galbraiths patch fører så voldsomme forbedringer af ydelsen med sig ved desktop-brug, at skaberen af Linux, Linus Torvalds, i en e-mail har de helt store roser fremme.

»Jeg er meget glædeligt overrasket over, hvor lille patch'en er endt med at blive, og at den ikke er forstyrrende for kernekoden eller ser grim ud,« skriver Linus Torvalds, der samtidig kalder patch'en en kæmpe forbedring.

Grupperer relaterede processer

Sagt mere teknisk er der tale om en optimering af den måde, Linux-kernens scheduler arbejder på.

Artiklen fortsætter efter annoncen

Schedulerens opgave er at prioritere, hvornår og hvor længe en proces skal have CPU-tid ? en afgørende del af styresystemer, der understøtter multitasking.

Mike Galbraiths patch genner relaterede processer sammen i såkaldte kontrollerede grupper, så scheduleren får mulighed for at prioritere CPU-tid til visse processer, når CPU'en er på overarbejde.

Ifølge Mike Galbraiths egne tests reducerer patch'en den gennemsnitlige latency - ventetid - ved desktop-brug med cirka en faktor 60.

Konsekvensen bliver, at du ikke skal daske musen frustreret ned i bordet så ofte som før, når e-mail-programmet eller browseren virker sløv, hvis du for eksempel er i gang med at oversætte en ny version af Linux-kernen eller brænde en dvd i baggrunden.

Artiklen fortsætter efter annoncen

Linus Torvalds hæfter sig især ved, at hjemmesider hentes meget hurtigere frem på skærmen under kraftig belastning af CPU'en på et Linux-system, hvor kernen er blevet patchet med Mike Galbraiths kode.

»Måske burde netop dét ikke være en overraskelse, men jeg har altid forbundet den slags med netværksydelsen. Det står nu klart, at hvis du har en CPU-belastning på 50 procent eller mere, så vil du normalt løbe tør for CPU-tid under nedhentningen af hjemmesiden og vil dermed sandsynligvis ikke modtage alle HTTP-forespørgslerne hurtigt nok,« skriver Linus Torvalds.

Ventes optaget i version 2.6.38

Phoronix.com har afprøvet patch'en på version 2.6.37, som er den kommende udgave af Linux-kernen. Som det kan ses i deres videopræsentation, er de stærkt imponerede over forbedringen af ydelsen.

Udviklingen af Linux-kernen fungerer groft sagt som ét stort sammenskudsgilde af kodebidrag fra erfarne programmører verden over.

Ind imellem sker det dog, at én enkelt programmør med et slag forbedrer Linux-kernens ydelse markant med ganske få linjer C-kode.

Det har også tidligere været tilfældet med danske Jens Axboe, som blandt andet har skrevet en ny mekanisme til version 2.6.32 af Linux-kernen, som gør udskrivning af data fra kernen til disken mere jævn og fair.

Mike Galbraiths patch kan ikke nå med i version 2.6.37 af Linux-kernen, men ventes optaget i version 2.6.38.

22 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
19. november 2010 kl. 08:59

Hvis man vil prøve at se om det påvirker ens system, men ikke har lyst til at patche og oversætte en ny kerne, er det faktisk muligt med en smule shell-scripting.

Det eneste patchen sådan set gør, er at automatisere oprettelsen, sletningen og tildelingen af cgroups, men selve cgroup funktionaliteten eksisterer i forvejen i kernen.

Der er informationer omkring hvordan det kan sættes op her:

http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

4
19. november 2010 kl. 11:26

Mike Galbraiths patch kan ikke nå med i version 2.6.37 af Linux-kernen, men ventes optaget i version 2.6.38.

Dvs. den kan mulig komme ud med 2.6.39 (lige numre er udvikling).

5
19. november 2010 kl. 11:43

Det er kun det midterste tal som angiver udviklings kerner.

8
19. november 2010 kl. 12:01

Det er kun det midterste tal som angiver udviklings kerner.

Ikke længere.

Før 2.6 betød ulige [i]major revision[/i] numre, at det var udviklingsversionen (altså 1.1, 2.1, 2.5 og lignende)

Svjv ligger udviklingen nu indenfor samme versionsnummer (2.6) men i det såkaldte 2.6-linux-next træ.

Se evt. http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux, Google, og Wikipedia.

7
19. november 2010 kl. 11:53

En patch der prioritere programmerne som brugeren interagere med og kan se på bekostning af programmer brugeren ikke kan se... det er ikke faktisk ydelse det er observeret ydelse. Ja det virker hurtigere men det er faktisk ikke hurtigere generelt.

Hvad er overheadet for denne fantastiske inovation ? og er det svært anderledes end hvis man satte alle baggrunds programmer til at køre med nice flag eller er det endnu bedre at man reservere et vist antal timeslots til brugerinterfacet som der så ikke bruges til baggrundsprocesserne på noget tidspunkt ?

og hvis det at brænde en DVD optager mere end 50% af din CPU så er det seriøst tid til at købe en ny maskine.

og at oversætte end linux kerne hvad betyder det helt præcist... jeg troede man kompilerede den slags.

go weekend Jakob

16
19. november 2010 kl. 18:48

Kurset omhandlede teorien bag compilere - eller oversættere, som jeg bestemt vil mene er en gangbar, dansk oversættelse (sorry) af det engelske ord.

"To Compile" er på dansk at "Oversætte" - og det er den gængse betegnelse. Det giver også voldsomt god mening. En Compiler/Oversætter omskriver et programmeringssprog til et andet. Som regel er der tale om at et sprog fra højere niveau, C, Java, el.lign., oversættes til et sprog af lavere niveau: x86 assembler, JVM bytecode, og så videre. Men der er også eksempler på oversættere der går mellem assemblertyper, fra Scheme til C eller har samme kilde og målsprog, oversættelse fra C til C eksempeltvist.

Det væsentlige i oversættelsen - det som programmøren beror på - er at oversætteren bevarer semantikken i programmet. Altså at programmets mening, "det programmet gør", er det samme før som efter oversættelse.

17
20. november 2010 kl. 03:25

"To Compile" er på dansk at "Oversætte" - og det er den gængse betegnelse. Det giver også voldsomt god mening. En Compiler/Oversætter omskriver et programmeringssprog til et andet.

Det er nemlig helt korrekt. Sjovt nok kan sprogsjuskere, der er fortalere for "compilere/kompilere" andrig drømme om at "interpretere" et sprog, men kan her godt finde ud af at "fortolke" det.

18
20. november 2010 kl. 17:18

har altid ignoreret dansk fagnomenklatur fordi jeg mener det er meningsløst. Det sagt er jeg ikke datalog og den danske fagnomenklatur eksistere åbentbart.

Jeg ser frem til at computere bliver til datamater og linkere bliver til sammenkædere... at kalde compilere oversættere er lidt underligt eftersom computere hedder computere og ikke datamater. selvfølgeligt er der en kontekst i denne udgivelse som næppe bliver overset men skulle mene at den gænse forståelse af ordet "oversættere" er mennersker der arbejder med at oversætte tekst og tale.

At der findes en kryptisk dansk nomenklatur der oversætter ordet "compiler" med "oversætter" er imo en lidt tåget dansk oversættelse eftersom "compiler" ikke er lig med "translator".

"At kompilere" er et dansk udtryk og "to compile" er et engelsk udtryk der overlapper i deres oversættelse. Så at de engelske ord "compiler" og "translator" og de danske ord "oversætter" og "oversætter" åbentbart er mindre forskellige end det danske ord kompiler som åbentbart ikke findes men ordet "computer" gør er hvad man kunne kalde en semantisk uenighed.

hvis man ser på en gængs beskrivelse af hvad en compiler er

"Computing (of a computer) convert (a program) into a machine-code or lower-level form in which the program can be executed."

kalder det at konvertere det til maskinkode er så hvad det er men der er åbenbart nogen der konvertere engelsk til fransk.

Alt sagt så undskylder jeg at jeg kritiserede tekstens valg af danske fagudtryk, version2.dk er nok det sidste sted den korrekte danske fagnomenklatur indfor datalogi benyttes. Er der nogen der vil kontakte dansk sprognævn for jeg tror version2.dk udføre et prisværdigt arbejde med at bevare den danske sprogrigdom ved at benytte disse i høj grad udrydningstruede fortolkninger af det danske sprog og i bør anderkendes for dette. En mulighed kunne være at sætte et professorat op på "IT-Universitetet" - jeg har hørt at de har en forkærlighed for ironi ;)

Go weekend. /Jakob

19
20. november 2010 kl. 19:03

Jeg ser frem til at computere bliver til datamater og linkere bliver til sammenkædere...

Du har tydeligvis aldrig været på DIKU. Det er stedet hvor bærbare hedder mappedatamater :-)

God weekend :P

20
20. november 2010 kl. 21:43

Når nu J-lo håndhæver korrekt dansk sprogbrug, burde han være vare sin mund og kalde det disk tilgang og ikke disk access :0).

Derudover er jeg helt enig. Når der nu er danske ord som dansktalende kan og vil forstå bedre end et engelske ord. Så giver det selvfølgelig mening at bruge det når man snakker og skriver dansk. Det betyder ikke at der er begreber som viser sig svære at oversætte. f.eks. mangler vi stadig en fornuftigt oversættelse af "race condition" :(.

23
21. november 2010 kl. 00:50

Det betyder ikke at der er begreber som viser sig svære at oversætte. f.eks. mangler vi stadig en fornuftigt oversættelse af "race condition" :(.

Samtidighedsproblem er da et udmærket udtryk.

24
21. november 2010 kl. 07:38

Vil nu mere at samtidighedproblem nærmere er en fælles betegnelse for en masse problemer, hvor race condition er et af dem. Et andet er foreksempel dead lock.

25
21. november 2010 kl. 15:55

@Anders, ja samtidighedsproblem er mere en klasse af problemer. Men nok det bedste der er.

En dead lock er netop en baglås. Ve den der skriver dødslås :)

21
20. november 2010 kl. 22:29

Oversætter er faktisk et bedre udtryk end det engelske "compiler". Oversætte er hvad programmet faktisk gør. "Compile" betyder noget med at sammensætte dele til en helhed, hvilket mere er i stil med hvad en linker gør.

22
20. november 2010 kl. 23:36

Jeg har brugt meget tid i ledige stunder på at spekulere på, hvorfor nogle danske fagtermer er blevet accepteret og derfor blevet brugt - hvorimod andre udløser hån, fnis eller fnys, hvis man forsøger sig med dem.

Diskussionen er bestemt ikke ny; den var allerede godt i gang før 1980, selvom antallet af accepterede danske udtryk muligvis er faldet siden da.

9
19. november 2010 kl. 12:17

Det er rigtigt at patchen ikke gør processoren hurtigere. Hvis man vil have en hurtigere processor er det en ny hurtigere processor.

Hos mig er patchen yderst anvendelig:

Jeg har: $ uptime 12:08:11 up 5:47, 2 users, load average: 0.62, 0.66, 0.72

som det ses er mit system der ikke er under voldsom stor belastning, men der er spidsbelastninger hvor load stiger voldsomt, og så suxs Firefox max - kopiering af tekst tager omkring 6 sekunder før menuen er tegnet på skærmen, og skift til et andet faneblad tager 8 sekunder.

Af en eller anden grund klarer Chromium det meget bedre - ingen ventetid som er irriterende (vel mindre end 0,5 sekund), så det kan selvfølgelig også være at der bare er en fejl i Firefox der går voldsomt ud over performance for mere end ca 8 faneblade.

Jeg skal helt klart prøve at have patchen med i en custum 2.7 kerne.

15
19. november 2010 kl. 18:39

Af en eller anden grund klarer Chromium det meget bedre - ingen ventetid som er irriterende (vel mindre end 0,5 sekund), så det kan selvfølgelig også være at der bare er en fejl i Firefox der går voldsomt ud over performance for mere end ca 8 faneblade.

Det skyldes at Firefox har et mindre smart design hvor hver sidevisning ender med at skulle forbi disken og snakke med deres sqlite database. Disk access er som bekendt blandt noget af det dyreste du kan foretage dig. Specielt hvis din disk er belastet af andre ting i mellemtiden, hvorefter du kommer til at skulle vente lang tid.

12
19. november 2010 kl. 13:09

Jeg skal helt klart prøve at have patchen med i en custum 2.7 kerne.

Så risikerer du at skulle vente meget længe:http://www.groklaw.net/article.php?story=20051106172616929

Please, please, please, let SCO ask the court to sanction IBM for refusing to hand over the 2.7 materials. Pretty please?</p>
<p>[b]Linux 2.7 not only doesn't exist, there are no current plans to have one.[/b]

Det gamle even/odd versionsnummer-system blev droppet i 2004 for Linux-kernen!

Hvis man efter 6 år bliver ved med at plapre om ulige/lige som ustabil/stabil Linux-kerne (eller endda omvendt, hvilket jo er helt i hegnet!), så ved man altså for lidt om Linux-kernens versionsnumre til at udtale sig om dem.

13
19. november 2010 kl. 13:17

Ja det var en typo - jeg kom af en uforklarlig årsag til bruge det 2.7 en havde skrevet tidligere.

Jeg mente 2.6.37-rc2 (og jeg ved godt at versionsnummerering er ændret)

11
19. november 2010 kl. 12:34

Af en eller anden grund klarer Chromium det meget bedre - ingen ventetid som er irriterende (vel mindre end 0,5 sekund), så det kan selvfølgelig også være at der bare er en fejl i Firefox der går voldsomt ud over performance for mere end ca 8 faneblade.

Chrome/Chromium har en process pr. faneblad og firefox har en process i alt, er det ikke nok til at forklare forskellen?

Som jeg har forstået det, så prøver CFS scheduleren så vidt muligt at fordele processor tiden ligeligt imellem alle de aktive processer på maskinen. Hvis vi siger at firefox kører sammen med 4 andre processer der alle gerne vil bruge 100% CPU tid, kan firefox så maks få 20% (1/5) af CPU'ens tid. Chrome derimod har mindst 2 processer (som har en eller anden arbejdsfordeling jeg ikke er 100% på hvordan virker), hvilket så betyder at den kan få tildelt 33% (2/6) af CPU tiden.

Grunden til at patchen så hjælper din firefox, er at de 4 CPU tunge processer nu vil blive betragtet af scheduleren som 1 process, og derved vil firefox få 50% af CPU tiden til rådighed.

3
19. november 2010 kl. 09:56

Jeg er imponeret over at 233 linier kan gøre så stor en forskel...

Det er dælenme godt gået.