Den fantastiska linuxpatchen, när?

Det ska ju komma en patch som ska göra linux rejält snabbare. Kommer med i version 2.6.38. Någon som vet nåt när? Själv använder jag ubuntu. Har lyckats googla att man i ett terminalfönster skriver "cat /proc/version" för att se vilken version man har. Mer detaljerad info här nedan.



En liten patch på bara 233 rader kod kan innebära att Linuxkärnor blir flera gånger snabbare. Det blir en mycket positiv överraskning säger Linuxgrundaren Linus Torvalds.
Nästa revision av Linuxkärnan ser ut att innebära ett rejält prestandaskutt sedan en av utvecklarna, Mike Galbraith, presenterat en patch på oansenliga 233 rader kod men med stor potential.

Enligt de preliminära uppgifterna kommer patchen att kunna snabba upp en del processer tio eller kanske rentav 60 gånger. Det handlar inte minst hantering av högupplösta videofiler och annat som kräver lite mer av operativsystemet. Linuxgrundaren Linus Torvalds har tagit ett titt på Mike Galbraiths arbete och ger tummen upp.

– Jag är både mycket glad och förvånad över hur en liten patch som denna kan göra så stor skillnad. Det här handlar verkligen om en stor förbättring, säger Linus Torvalds i ett uttalande:
http://marc.info/?l=linux-kernel&m=128979084506774&w=2

Ännu återstår lite arbete för att baka in Mike Galbraiths arbete i Linuxkärnan men det ska finnas på plats i version 2.6.38.

Det verkar som Ubuntu får 2.6.38-kerneln i sin Natty-release, dvs version 11.04. Jag har dock inte sett om den förändringen verkligen följer med i ubuntu-kärnan.

http://blogs.computerworld.com/17371...e_a_lot_faster Mer information.

http://www.phoronix.com/scan.php?pag...37_video&num=2 2 videor som testar performance med och utan patchen.

Väldigt intressant! Hur går man till väga för att få tag på patchen och installera den? Någon som vet om debian kommer slänga in patchen anytime soon ?

Här har du patchen, fanns i din första länk
http://marc.info/?l=linux-kernel&m=128978361700898&w=2

Bara att patcha och kompilera om din kärna om du inte orkar vänta

Hur du patchar finns i kerneldokumentationen.

Att säga att patchen gör Linux snabbare är felaktigt. Enda skillnaden är att program prioriteras annorlunda så att interaktiva program känns snabbare. Enda gången man märker det är när man belastar systemet hårt samtidigt som man använder interaktiva program. Folk som inte kompilerar kernlar dagarna i ända märker antagligen ingen skillnad alls. Jag har använt patchen i några veckor och har inte märkt någon skillnad. Jag kompilerar ofta saker samtidigt som jag surfar men jag kör alltid kompileringar på lägre prioritet så skillnaden går inte märka.

Om man vill se fram emot 2.6.38 så tycker jag att de sista VFS scalability patcharna och den nya huge pages koden är mer intressant.

https://lwn.net/Articles/423584/
https://lwn.net/Articles/419811/

Glädjedödare, för personer som tex ofta renderar musik/videofiler osv bör detta göra drastiska skillnader i vardagsanvändande. Vad är VFS Scalability?

Bara om du gör renderingen i en separat TTY/PTS. Annars körs allt under samma och då blir det ingen skillnad.

Själv kör jag med BFS, vilket balanserar systemet väldigt bra. http://ck.kolivas.org/patches/bfs/bfs-faq.txt

2.6.38 finns ute och jag fick den idag när jag uppdaterade med pacman, dock vet jag inte om patchen finns med, har inte orkat kolla eller ta reda på det.
Ska testa prestanda när jag kommer hem från jobbet idag och se om jag märker någon skillnad.

Jo, den finns med i 2.6.38. Men det lär bara bli några procent snabbare. Du lär se större skillnad om du byter till en mer lightweight fönsterhanterare, som t.ex. openbox.

Det här är ganska fel.

Folk verkar inte riktigt vara insatta i vad den här patchen gör (Edit: förutom Akina då). Följande är mitt försök till att förklara det så gott jag förstått det.

Patchen gör så att varje TTY och PTY grupperas i en egen cgroup. Varje cgroup kan i sig inte helt roffa åt sig all prestanda, utan måste dela den med de andra cgroups.

Så vad innebär det här?

Din dator blir inte snabbare av den här patchen. Det är inte heller dess syfte. Dock bör den bli mer responsiv, beroende på vad du gör. Startar du ett väldigt processorintensivt program (exempelvis en kompilering) i en separat PTY eller TTY så kommer det inte att kunna sno åt sig hela processorn, utan det som körs i en annan PTY eller TTY kommer också fortfarande kunna köras utan uppehåll.

För att starta program i en separat PTY i X så behöver du i nuläget köra dem i terminal. Det gör det väldigt svårt att balansera för saker som flash, eftersom det vanligtvis ligger under samma PTY som webbläsaren (som ligger i samma PTY som skrivbordsmiljön eller fönsterhanteraren). Det har varit snacka om att ändra freedesktop-standarden så du ska kunna starta program under en separat PTY vilket skulle innebära att den här patchen verkligen kommer i sin fulla nytta. Om det kommer eller ej får vi bara vänta och se.

Så med andra ord, för att utnyttja den här patchen i dagsläget måste du starta de olika krävande sakerna i olika PTYer, vilket är enklast att göra genom att starta det från en terminal. Ett exempel vore att köra igång en kompilering med -j32 och en HD-film med mplayer i två olika terminaler och se hur responsiv skrivbordsmiljön är medan du använder den.

Sen behöver man inte använda den här patchen heller om man inte vill, man kan använda sig av ett script i init för att automatiskt gruppera de olika TTYerna eller PTYerna i olika cgroups. Funktionaliteten för att inte låta en cgroup roffa åt sig allt har funnits i kärnan ett tag. Det enda den här patchen gör är att det sker automatiskt istället.

Här finns mer information.

Spelar det någon roll vilken schemaläggare man väljer? Jag kryssade enbart i CFQ när jag kompilerade 2.6.38 och kryssade ur alla andra.

Jag tror inte CFQ har särskilt mycket att göra med den här patchen. CFQ styr ju bara i/o från lagringsenheterna. CFS däremot hanterar schemaläggning av processorn, men den kan du ändå inte byta efter kompilering.

Con Kolivas som utvecklat BFS har hittills inte portat sina patchar till 2.6.38. Hans patchar har också redan väldigt bra fördelning mellan processer att den här patchen kanske inte ens kommer ha särskilt mycket påverkan.

Sen vet jag inte om den här patchen kräver någon förändring i schemaläggaren, om inte så bör det funka automatiskt med vilken schemaläggare som helst.