Kleine kernel-patch laat Linux desktoptaken vloeiender verrichten

Het toevoegen van slechts 224 regels code blijkt voor veel vloeiender werking van doorsnee desktoptaken op Linux te zorgen. Linus Torvalds, geestelijke vader van Linux, is enthousiast over de patch.

Het gaat om het toevoegen van 224 regels code en het verwijderen van 9 regels. Dit zorgt ervoor dat er automatisch taskgroups per tty worden aangemaakt: door het op deze manier scheiden en isoleren van zware werklasten van doorsnee desktoptaken wordt voorkomen dat de zware taken die op de achtergrond draaien alle processortijd van desktop-taken in beslag nemen, en daarmee het systeem onresponsive lijken te maken. Tty is het voor Linux essentiële subsysteem dat het draaien van zowel fysieke als dynamische terminals mogelijk maakt. Met dit systeem wordt liefst zo min mogelijk geëxperimenteerd omdat wijzigingen onbedoelde gevolgen kunnen hebben.

Het idee voor de patch is afkomstig van Linus Torvalds zelf en de code is geschreven door Mike Galbraith. Inmiddels wordt aan de derde versie gewerkt, maar de patch is nog niet in de kernel opgenomen. "De patch verbetert dingen als vloeiend scrollen, maar het interessante is dat websites veel sneller lijken te laden", aldus Torvalds.

De maximumlatency van een desktop-Linux-systeem zou door de patch met een factor tien zijn teruggebracht. Phoronix heeft de patch getest met een systeem dat Ubuntu 10.10 draaide en een Intel Core i7 970-processor bevatte. De site gebruikte de Gnome-desktopomgeving en draaide een 1080p-video in ogg-formaat, glxgears, twee openstaande Firefox-browsers die de Phoronix Test Suite-sites openden, twee terminal-vensters, de Gnome System Monitor en de Nautilus-filemanager.

Zonder de patch verrichtte het systeem de taken allesbehalve vloeiend, waarbij het videofragment zelfs helemaal stokte. Het systeem laat met de patch ingeschakeld een heel ander beeld zien; het reageert veel sneller en de 1080p-video speelt zonder stotteren af. Volgens Phoronix wordt het verschil nog groter als de werklast wordt verhoogd.

Reacties (177)

[freggy]

De hype die rond deze patch gecreëerd wordt is zwaar overdreven. Dit verbetert helemaal niet de performantie tijdens normaal grafisch desktopgebruik, simpelweg omdat alle programma's die je grafisch opstart niet in een tty worden opgestart. Deze patch heeft enkel enig effect wanneer iemand processen gaat opstarten vanuit een terminal. Leuke verbetering dus voor wie wat aan het compileren of number crunchen is in een terminal en ondertussen zijn videospeler opstart vanuit een andere terminal, maar dat is toch niet bepaald de manier waarop een gemiddelde desktopcomputergebruiker werkt...

http://lkml.org/lkml/2010/11/16/420

[Kees]

Sterker nog, iemand die een usecase als deze heeft zou waarschijnlijk meer gebaat zijn met normale limitatie van zijn processen (bv, niet met -j64 compileren als je niet minimaal 32 cores hebt, en zelfs dan zou ik het met maximaal -j16 oid doen).

De patch ziet er heel leuk uit, in een extreme situatie. Maar het nadeel van extreme situaties is dat ze in de praktijk vrijwel nauwelijks voorkomen.

Overigens heeft deze patch juist ook de potentie om de boel te vertragen, als je in plaats van 64 processen in 1 tty, 64 tty's met elk 1 proccess opent, dan zal je 'hoofd' tty (je desktop) meer vertragen en trager reageren dan als je deze patch uitzet.

[johnbetonschaar]

Misschien moet je even verder lezen in de thread die je zelf quote, want er zijn wel degelijk heel veel use-cases van grafisch desktop gebruik waar dit relevant voor is, wat ook in de reactie op het bericht waar je naar verwijst blijkt. Alles wat je vanuit een terminal (ook vanuit een xterm of gnome-terminal of iets dergelijks) draait opent TTY's, maar ook grafische applicaties die shell executes en dergelijke uitvoeren, bijvoorbeeld een video encoder die achter de schermen de command-line transcode tool aanroept, of een IDE die de compiler aanslingert, enzovoorts.

Als je alleen maar wat zit te browsen met een muziekje aan op de achtergrond zal je weinig verschil merken nee, maar vooral developers zullen erg blij zijn met deze patch omdat daar nog altijd heel veel command-line tools achter zitten.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 12:54]

[D-TECH]

Veel programma's gebruiken de terminal

[LinuX-TUX]

Vanochtend zag ik een mailtje van een collega voorbijkomen over dit nieuws.

Zit al bijna een jaar tegen dit probleem aan te hikken tijdens developpen. Grote java projecten, clean & build via maven op command line en dan maar rustig een lap tekst op het andere scherm klaarzetten om te lezen, want zelfs een beetje normaal muizen zit er dan niet meer in.

Net even de liquorix repository toegevoegd onder ubuntu, kernel geinstalleerd (welke gepatched schijnt te zijn) en echt in 1 woord, GEWELDIG!

Kan gewoon rustig nog een beetje door blijven testen/coden terwijl op de console op de achtergrond het 1 en ander compiled/getest wordt

Forum bron: http://www.phoronix.com/f...thread.php?t=27138&page=5
Liquorix bron: http://www.liquorix.net/

PS: Het is geen performance upgrade, het is een responsiveness upgrade
PPS: Tijdens het typen heb ik welgetelt 1 keer nagenoeg unresponsive desktop gehad. Maar dat komt meer door uit m'n geheugen lopen dan een niet werkende patch

[Wtrdk]

Heb je gewoon de repo zoals hij op die site toegevoegd en toen apt-get update && apt-get dist-upgrade gedaan? ('t is een debian repo, werkt dat zonder meer op Ubuntu Maverick?) Of heb je andere handelingen uitgevoerd?
Ik wil 't ook wel eens proberen!

[Reactie gewijzigd door Wtrdk op 23 juli 2024 12:54]

[LinuX-TUX]

Gewoon toegevoegd, apt-get update -> apt-get install <kernel pakketjes van liquorix>

In mijn geval:
linux-headers-2.6-liquorix-amd64
linux-headers-2.6.36-0.dmz.11-liquorix-amd64
linux-image-2.6-liquorix-amd64
linux-image-2.6.36-0.dmz.11-liquorix-amd64

Voor AMD64

Edit: Ja, werkt perfect onder 10.10 bij mij

[Reactie gewijzigd door LinuX-TUX op 23 juli 2024 12:54]

[Gijs007]

als linux newbie had ik er nog wat problemen mee op mijn x86 lubuntu distributie.

maar ben er uiteindelijk achter gekomen.
eerst moet je de repo (dit bestand /etc/apt/sources.list.d/liquorix.list)
met sudo(admin) rechten openen en dan deze lijn tekst er aan toevoegen en opslaan:
deb http://liquorix.net/debian sid main

daarna computer herstarten en dan: apt-get install '^liquorix-([^-]+-)?keyring.?'
apt-cache search liquorix

en dan in de terminal sudo apt-get update
als het goed is zie je nu een hoop tekst met url's langs komen en zitten er ook verwijzingen naar http://www.liquorix.net/ tussen.
daarna doe je sudo apt-get install linux-headers-2.6-liquorix
en als dat klaar is.
sudo apt-get install linux-image-2.6-liquorix

dan systeem herstart en in de bootloader zie je nu ook en liquorix tussen staan als standaard, gewoon op enter drukken en even wachten tot het systeem is opgestart.
werkt stukken sneller op mijn eerst trage 256 mb ram laptop met intel pentium 4 2.4 ghz processor en lubuntu 10.10.

[freggy]

Als ik snel even in de patch van liquorix kijk, zie ik dat die de Brain Fuck Scheduler van Con Kolivas gebruikt in plaats van de standaard proces-scheduler in de Linuxerkernel. Het is dus maar zeer de vraag of je verbetering in responsiviteit het gevolg was van de nieuwe patch of van BFS.

[Reactie gewijzigd door freggy op 23 juli 2024 12:54]

[Verwijderd]

De patchset van Con wordt wel toegepast, maar volgens de config wordt BFS sowieso niet gebruikt... Het is dus wel het net uitgebrachte patchje van ~200 regels code

[DutchSjors]

Dit is mooi, want Linux vond ik nooit zo snel. Een factor tien terugbrengen is ook niet niks,logisch dus dat Torvalds trots is.

[Reactie gewijzigd door DutchSjors op 23 juli 2024 12:54]

[johnydoe]

Helaas, deze patch maakt je systeem niet magisch sneller. In plaats daarvan _lijkt_ de desktop sneller doordat deze beter reageert door betere verdeling van taken. In het filmpje wordt bijvoorbeeld de kernel op de achtergrond gecompiled om de CPU last de verhogen. Je ziet dat alles toch vlot blijft lopen.... wat niet wordt genoemd in het artikel echter, is dat die compile nu wel langer duurt.

[Verwijderd]

In plaats daarvan _lijkt_ de desktop sneller doordat deze beter reageert door betere verdeling van taken.

Is dat niet eigenlijk wat je überhaupt wilt van je OS en je PC? Dat het ding soepel reageert?

De meeste mensen gebruiken hem, die zitten erachter terwijl het ding iets doet. Die hebben er constant interactie mee en willen dus niet oeverloos lang gaan zitten wachten.

Dat is ook de belangrijkste reden dat ik momenteel Firefox niet meer gebruik, om maar een voorbeeld te noemen. Tijdens het afspelen van iets groots dat gebruik maakt van Flash, zoals bijvoorbeeld een HD Youtube filmpje is de responsetijd van Firefox echt abominabel, zeker in vergelijking met de concurrentie.

Weer over deze wijziging voor Linux - in de toekomst zullen eventuele nadelige effecten van deze wijziging volledig verdampen, door de komst van 8-core, 16-core, 32-core (en meer) CPUs.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 12:54]

[YopY]

En toch vindt ik het als gebruiker het veel belangrijker dat de GUI goed responsief blijft en snel /lijkt/ dan dat een taak in de achtergrond (zoals het compilen van de kernel) snel blijft lopen. In Windows stoor ik me er ook regelmatig aan dat er ergens iets bezig is, waardoor de GUI gewoon niet meer reageert op klikken. Dat zou de hoogste prioriteit in een OS moeten zijn, mijns insziens.

[kidde]

Het vervelende - waar een grote groep Linux-gebruikers zich erg aan stoort - is dat Linus de kernel nooit voor hen (de desktop dus) heeft willen optimaliseren.

Er was eens een man genaamd Con Kolivas - die dit soort patchen ging maken zodat Flash-filmpjes voortaan vloeiend konden worden afgespeeld op Linux. Heette RSDL (Rotating Staircase Deadline Scheduler), nu is de anesthesist bezig met de simpelere opvolger BFS.

RSDL werd niet geaccepteerd door Linus bij gebrek aan 'afdoende bewijs' dat het echt sneller wás, en als resultaat hing Con z'n toetsenbord aan de wilgen. Kortom, het voelde sneller vonden velen, maar kon niet met benchmarks aangetoond worden, dus bleef Flash zuigen op Linux.

Ingo Molnar werd door Linus aan het werk gezet om te zorgen dat de kernel 'ietsje' sneller werd voor desktop-gebruikers, maar dat mocht niet ten koste van hen die supercomputers met "honderdduizenden processors" gebruiken, dus kwam er een Koksiaans-compromis genaamd CFS (Completely Fair Scheduler). Omdat de Linux-kernel moet schalen naar massieve multi-processing, is het dus eigenlijk zo dat de optimalisatie voor desktop vrij flut is.

DesktopWindows (kernel?) heeft deze optimalisatie voor desktops wel (want schaalt kennelijk toch voor geen drol naar HPC), en daarom dat de Linux-kernel op 'ervaring op multimedia-gebied" ook behoorlijk zuigt.

Fijn dat er nu eindelijk iets aan gebeurt, Linus houdt in z'n uppie optimalisaties voor de desktop al jarenlang tegen.

[H!GHGuY]

Het zou des te interessanter zijn, mocht je ook de realiteit even onder de loep nemen.

Linux is al heel lang een OS die zijn hoofd-marktaandeel in de server omgeving zoekt
en in mindere mate op de desktop.
Bovendien heeft Ingo (vziw met goedkeuring van Linus) al meerdere malen aangehaald dat de optimalisaties in de scheduler bedoeld zijn voor high-end hardware (op dit moment een 8-16 core processor).

Linus heeft altijd tegengehouden dat er meerdere schedulers in de kernel zouden zitten, maar hij heeft optimalisaties nooit tegengehouden, zolang ze geen grote performance regressies introduceren op andere belangrijke punten.
Trouwens zijn scheduler changes zowat de moeilijkste changes in de kernel. Benchmarks zijn zowat altijd slechts afkooksels van de echte performance. Daarnaast heb je ook altijd de throughput<=> latency afweging. Scheduler changes moeten typisch harder onderbouwen dat ze geen negatief neven-effect introduceren voor ze in de kernel mogen.
Typisch heeft het voordeel in 1workload een negatief op enkele andere workloads. Moet je de patch dan toelaten, of niet?

[BeosBeing]

Linux is al heel lang een OS die zijn hoofd-marktaandeel in de server omgeving zoekt en in mindere mate op de desktop.

Terwijl er bij het volk grote behoefte is aan een desktop-kernel, kijk naar de populariteit van Ubuntu en derivaten, die populariteit is er omdat het een desktop-OS is. De xBSD-varianten, zijn ook allemaal vooral bedoeld voor servers (Mac OS-X uitgezonderd) envenals OpenSolaris. De enige vrijen die zich blijkbaar wel op de desktop richten zijn Haiku, ReactOS en natuurlijk Freedesktop.org.
...

Linus heeft altijd tegengehouden dat er meerdere schedulers in de kernel zouden zitten, maar hij heeft optimalisaties nooit tegengehouden, zolang ze geen grote performance regressies introduceren op andere belangrijke punten.

Mischien is het zinvol om twee of drie schedulers er in te zetten, waarvan er slechts één actief kan zijn. De drie zouden dan zijn: 1 servertoepassingen, 2 desktop-toepassingen, 3 all-round.

Bovendien heeft Ingo (vziw met goedkeuring van Linus) al meerdere malen aangehaald dat de optimalisaties in de scheduler bedoeld zijn voor high-end hardware (op dit moment een 8-16 core processor).

Terwijl Linux-systemen altijd zijn geroemd om hun lage systeemvereisten (vooral omdat je geen GUI nodig had, maar die GUI is steeds vanzelfsprekender geworden en ook steeds zwaarder de laatste 10 jaar) en er een groot aantal distributies is die zich specifiek richten op low-class computers (Damn Small Linux, Puppy Linux, Feather Linux, DeLi, Vector Linux, Zenwalk, Antix, PClos TinyME, U-lite, Crunchbang Linux, SliTaz, Masonux, WattOS, Lubuntu, OzOS, MoonOS...diverse versies voor netbooks) en vooral op routers en telefoons (Android, WebOS, MeeGo, Maemo) maakt het nu furore. Kortom, waarheen ontwikkelt de rest van de markt.

Lijkt mij dat je als 3e of 4e scheduler eens kunt kijken in die richting: bedoelt voor ultra-lightweigt systemen: zonder Gui (aka routers) of juist sterk GUI-based zoals telefoons, mediaspelers (bv Archos), netbooks/smartbooks en telefoons.

Het zou des te interessanter zijn, mocht je ook de realiteit even onder de loep nemen.

Linux heeft sterke allround-kwaliteiten, en kan op vele gebieden effectief ingezet worden, maar het lijkt mij dat in de praktijk het grootste toepassingsgebied nu juist ligt op apparaten die je niet echt krachtig of high-end kunt noemen, tenzij me uiteraard Samsungs Galaxy Tab, en Galaxy S en HTC's Desire HD en Desire Z als high-end bestempeld, maar dat zijn nou niet bepaald dingen met 8-16 cores.

Volgens mij luistert Linus dus niet echt naar de markt.

[Verwijderd]

Het vervelende ... Linus houdt in z'n uppie optimalisaties voor de desktop al jarenlang tegen.

Thumbs up. Echt, interessant stukje om te lezen.

[Delgul]

Als Linus die patches wel had geaccepteerd was deze patch waarschijnlijk nooit meer ontwikkeld. Je had dan gezeten met een systeem dat enkele procenten sneller werd (misschien), maar nooit meer van de factor 10 improvement mogen genieten.

Ik denk dat iedereen het erover eens is dat deze patch veel beter is dan al de voorgaande en dat het idd niet ten koste gaat van de server performance.

m.a.w. Ik denk dat Linus weer eens gelijk had als je naar de lange termijn kijkt. En Open Source gaat meestal over langere termijn...

[Slother]

dat is niet de opdracht van het systeem, maar wel van de ontwerpers van dat specifiek stuk software dat threads moet gebruiken om de gui draaiende te houden, ik weet niet hoe he zit wat betreft software op linux, maar software op windows besturingssytemen bepalen nog altijd zelf hoe snel hun gui reageert

[the_stickie]

Als je het zo uitlegt lijkt het natuurlijk "boerenbedrog". Maar het is wel wat in feite gebeurt: door slimme prioriteiten te leggen hoeft een gebruiker niet te wachten op de interface. Dat wachten wordt immers als zeer ergerlijk ervaren.

Ik ken zelf de Microsoft OS'en veel beter, en daar zie je dergelijke truuks ook terugkomen: als een proces bijvoorbeeld audio afspeelt in Vista/7 krijgt dat process een reservatie in clockcycles, zodat rekenintensieve applicaties geen gestotter meer kunnen veroorzaken.

edit:
* the_stickie kijkt naar beneden

* the_stickie bedenkt dat hij nooit over MS had mogen beginnen als het over linux gaat

[Reactie gewijzigd door the_stickie op 23 juli 2024 12:54]

[MrSnowflake]

Zoals je zegt: lijkt, maar dat is het natuurlijk niet.

Volgens mij zou een systeem dat zeer snel reageert maar in feite langzamer is als een systeem dat minder snel reageert, maar dat sneller is (het eerste systeem heeft een Core i3 en het 2de een i7), dan zal een gebruiker toch zeggen dat het eerste systeem sneller is.

Onderzoek wijst uit dat het wachten op een actie korter aanvoelt als het progress balkje geanimeerd is tov een statisch balkje (balkje XP tov 7). Hoewel de wachtijden hetzelfde zijn.

[Reactie gewijzigd door MrSnowflake op 23 juli 2024 12:54]

[BeosBeing]

Onderzoek wijst uit dat het wachten op een actie korter aanvoelt als het progress balkje geanimeerd is tov een statisch balkje (balkje XP tov 7). Hoewel de wachtijden hetzelfde zijn.

Echter het animeren van dat balkje kost processortijd waardoor de wachttijd langer wordt. Zet er dan een klok in met een percentage of een nog te verwachte duur, zodat de gebruiker weet dat hij koffie moet gaan drinken.

Waar ik me altijd zo over verbaas bij Windows 3.11 en alle opvolgers is dat als de cpu 100% belast is en het systeem niet meer reageert op toetsaanslagen, oproepen van taakvenster, zelfs <ctrl>-<alt>-<delete> nog wel een animatie gedraait kan worden, de muis bewogen kan worden en er soms zelfs op bepaalde dingen geklikt kan worden op dingen op te starten (maar op programma afsluiten of opslaan niet)

[Verwijderd]

"Inmiddels wordt aan de derde versie gewerkt, maar de patch is nog niet in de kernel opgenomen."

Vanavond maar eens mijn kernel patchen Ben wel in voor een beetje alpha / beta testen

[beerse]

Als je microsoft os-en beter kent, dan mag je wel eens verklaren waarom er allemaal 'optimalisatie' processen draaien waar het origineel ook geoptimaliseerd had kunnen worden... Een voorbeeld: de laatste tijd zie ik op diverse windows servers (w2k3) waar de search-indexer 100% van 1 cpu gebruikt... Overigens, niet de indexer die je met windows-installatie kan aan zetten, maar de als update geïnstalleerde indexer... (nee, doe maar geen antwoord in deze draad...)

[Verwijderd]

Dat proces loopt op lage prioriteit dus waarom zorgen maken.

Als je het nutteloos vindt, installeer het dan ook niet of configureer het zoals jij wilt dat het werkt.

[Verwijderd]

Precies. Je wilt juist dat de indexer 100% van 1 cpu gebruikt, wanneer er geen andere processen gebruik van maken. En dat is precies wat het systeem doet, door de indexer op achtergrond prioriteit te draaien. Ieder normaal process krijgt voorrang wanneer het iets zou willen doen. (Ook qua disk I/O, want ook dáár heeft de indexer lage prioriteit)

Een cpu die niet gebruikt wordt is een ongewenst situatie, wanneer er nog wel achtergrond take zijn die niet af zijn. Zelfs met ongebruikte RAM... dat staat volkomen nutteloos te zijn. Liever het voor cache gebruiken, wat onmiddelijk vrijgegeven kan worden.

[BeosBeing]

Als het indexeren voltooid is hoeft die indexer ook niets meer te doen, anders doet hij effectief niets anders als een core belasten en daarmee de accu leegtrekken, of effectief verhinderend dat de andere core hoger geklokt kan worden als je Intel Turboboost of AMD Turbo Core hebt.

Daarbij, zijn mijn documenten (spreadheets, tekstverwerkingsdocumenten, PDF's) en thuis ook de Muziek- en Video- en Fotobestanden logisch gestructureerd(al kan het met de foto's nog wel beter, heten nu allemaal SL550001.jpg tm SL552275.jpg (compact) oid (d-slr) maar ze staan allemaal bij elkaar in dezelfde mappenstructuur deels gesorteerd op onderwerp/tijdstip e.d.) dus als ik de zoekfunctie gebruik, dan is het voor dll's (in %windir%\system, %windir%\system32, %windir%\WinSXS enz), ini's, inf's bepaalde exe's enzovoorts, steevast bestanden die niet geïndexeerd worden en laat je ze wel indexeren dan kun je ze met de zoekfuncties van Vista en Win7 nog niet vinden, zelfs niet als je het verbergen van extenties voor bekende bestandstypen uit zet, 'verborgen bestanden verbergen' en 'beveiligde besturingssysteembestanden verbergen' uit zet en zoekt met .dll, .ini, .inf of .exe in het zoekvenster. Althans op sommige systemen vind je het dan wel, op de meeste niet, ik gebruik dan meestal maar weer dir /s bestandnaam.ext en dan duurt het wel gigantisch lang maar je vindt tenminste wat je zoekt.

[BeosBeing]

Tja, mijn ervaring met Windows is ook dat het vaak de meeste processortijd geeft aan zijn eigen achtergrondservices en dingetjes die Microsoft belangerijk vind om voor je te doen maar die voor de gebruiker hindelijk zijn (zoals animaties die standaard een bepaalde minimumtijd moeten vergen en op een systeem dat langzamer is als waarop de devellopers het OS hebben gemaakt dus een eeuwigheid duren) en die dan ook nog eens vaker dan normaal vast lopen.

90% van de keren dat mijn applicatie niet meer reageert (of traag) ligt het aan explorer die op de achtergrond is gecrasht, (of de cpu bezig houd voor de flauwekul). Gelukkig is dat in W2K (sp4 eerdere sp geen ervaring mee), XP (vanaf sp1) en Win7 minder is geworden als in de oudere versies. Vista had er, naar mijn ervaring, ook veel last van, zij het dat mijn ervaring bij Vista Home (Acer notebook) heel anders is als bij Vista Business (HP desktop). Bij de eerste moet je alle driver-updates zelf bij de Acer site ophalen want Vista kan dat daar niet, de tweede doet dat wel, maar in Windows ME, 98se, 98, 95osr2.5 (gebundeld met IE4) was het zoom de twee uur.
Van de overige 10 procent komt er 9 door geheugentekort en swappen icm onvoldoende cpu-kracht.

[mensoc]

Nou dat werkt in vista in ieder geval NIET!
Als ik muziek afspeel en de standaard windows explorer aanzet(die standaard gewoon 100% van een van de cores gebruikt, compleet absurd uiteraard), dan hoor je af en toe een stotter in de muziek.
En het maakt dan niet uit of ik vlc player, bs player of wm player gebruik.
Typisch een van de kansloze amateuristische trekjes van het totaal mislukte vista.

En we gaan niet vista sp3, windows 7 genaamd, kopen, maar zijn bezig alles te migreren naar linux!

[Pure_evil]

Mooi zo, alsmeer meer redenen om mijn volgende (en deze hopelijk ook, nogal exotisch mobo, wilt niet altijd even vlot werken op linux) een dual boot te laten draaien.

Klein vraagje toch, is er in win7 eens wat beter gekeken naar wat prioriteit moet krijgen ivm disk acces? Draai hier namelijk nog XP en jezus, als ik es een 100 gig filmpje van mijn zus haar camcorder wil overzetten van 1 hd naar een ander mag ik net zo goed een uurtje tv gaan kijken want mijn pc wordt gewoon onbruikbaar. Dat het bij verder gebruik anderhalf uur duurt kan mij echt geen moer schelen, ik lees toch maar wat nieuws ed dan.

Klopt btw ECHT niet dat een explorer window 100% gebruikt oO

[mahsalti]

gebruik totalcommander voor dataoverdracht, dan kun je de transferrate zelf instellen zoals je wilt..

[Verwijderd]

In Vista is de disk-IO flink veranderd en heb je een I/O prioriteiten systeem naast het cpu prioriteiten systeem. Dat is in Win7 natuurlijk gewoon meegenomen. XP is gewoon verouderd.

[BeosBeing]

Verouderd en toch op vele punten beter. Uiteraard hebbem Vista en Win7 een mooiere GUI, ondersteuning voor de nieuwste hardware, meer features die XP en W2K niet hebben, enzovoorts, toch is XP gewoon beter in enkel doen wat de gebruiker vraagt en niets anders.

Microsoft heeft bij Windows altijd al te veel geprobeert voor de gebruiker te beslissen wat er gedaan moet worden. In veel gevallen is dat makkelijk, maar als je nu net wat anders wilde dan heb je pech want Windows/Word/Excel heeft voor jouw al bepaald wat er gedaan moet worden.

Nu is het voor minder ervaren gebruikers prima als voor hen al de juiste beslissing is genomen, en ook voor sommige meer ervaren gebruikers kan de gekozen optie toevallig net de goede zijn (zoals het .doc document openen met het geïnstalleerde MsWord) maar er zijn ook veel situaties waar die keuze niet de juiste is, en juist gebruikers die nadenken bij wat ze aan het doen zijn, en daar heel bewust een keuze maken die komen vaak tegen dat de automatisch bepaalde keuze voor hen niet de juiste is.

Net zoals ik in XP bij de zoekfunctie kon kiezen tussen muziek, films, documenten maar meestal bij geavanceerd een type bestand koos zoals "configuratie-instelling" (voor een .ini) of toepassingsextensie (voor een dll) en heel zelden een .wbk(Word backup), of zelfs een word .doc koos zo is juist die functie in Vista/Win7 verdwenen omdat Microsoft die, voor mij verkeerde, keuze heeft gemaakt.
Gelukkig heb ik ontdekt dat er nu een tooltje is genaamd everything, waarmee je toch weer daarop kunt zoeken.

Soms veranderd men dingen, niet ten goede, maar gewoon omdat men vind dat het er iets nieuws geïmplementeerd moet worden, nieuwe functies zijn goed voor de marketing. Echter als je vier wielen onder een auto zet, werkt het het beste als er twee links en twee rechts staan, en twee voren en twee achteren. Indien je één voorwiel in het midden hebt, en twee achterwielen, links en rechts (werkt prima bij driewielers) dan is het niet handig om daartussen nog een vierde wiel te zetten. Zoiets doen we wel voor iemand die nog moet leren fietsen: een fiets met zijwieltjes, maar voor normaal gebruik: bij normale fietsen voor normale mensen, komt het zelden voor.
Genoemde constructie is geen verbetering, toch komt zij voor bij o.a. de Mindanao Motorella (voorbeeldje: http://walksofkulot.files...motorella.jpg?w=300&h=200) waar men vanuit de bestaande constructie (motorfiets) geen andere mogelijkheid heeft om deze non-permanent geschikt te maken voor het vervoer van ± 8 personen, echter technisch bied deze constructie niet de mogelijkheid een voor een goede vering van het geheel, en dus is een lange rit niet uit te houden.

[Caelorum]

Als ik muziek afspeel en de standaard windows explorer aanzet(die standaard gewoon 100% van een van de cores gebruikt, compleet absurd uiteraard), dan hoor je af en toe een stotter in de muziek.

Volgens mij is er wat mis met de software, want ik heb dat gedrag nog nooit gezien.

[barfieldmv]

Dan is er iets mis met een driver van hardware. Of je sound drivers of een stukje hardware is te zwaar/slecht voor je systeem. Kijk eens of alles CPU door een usb drive oid word opgeslokt.

[engelbertus]

windows 7 is in mijn ogen toch wat meer als vista sp3....

veel bedrijven slaan vista over / mijden het als de pest, terwijl windows 7 wel wordt omarmd...

je zou dus zeggen dat win 7 toch stukken beetr presteert.

[Verwijderd]

Tja... dat laat alleen maar zien dat bedrijven nauwelijks meer kennis dat consumenten hebben. Want de verschillen tussen Vista sp3 en W7 zijn inderdaad marginaal.

Het grootste verschil is de naam, en de reputatie.

[Ge Someone]

Wanneer komt volgens jou SP3 voor Vista? Microsoft houdt zich nog op de vlakte. Zo hebben ze bij Windows NT 4.0 en Win2000 trouwens telkens het laatst aangekondigde Service Pack teruggetrokken.

[BeosBeing]

Sinds Vista (en dat geld deels nog steed voor Win7) duren sommige bewerkingen gewoon absurd lang. Na het selecteren van enkele tientallen files het verplaatsen daarvan naar een andere map, duur bij deze twee soms heel lang, hij is minutenlang continu aan het rekenen, zelfs voordat hij aan het verplaatsen zelf begint, en ook het het verplaatsen zelf gaat langzamer als bij XP die er gelijk aan begint en het in no time gedaan heeft (en dan vergelijk ik Vista/Win7 op een recente dualcore (Athlon TK-55 @1.8Ghz, Athlon M320, Intel Pentium dual-core @1 .8Ghz (desktop), C2D E8400) met XP op een antieke Pentium IV, Pentium III of zelfs een Duron @850 Mhz).

De grootte van de bestanden maakt niet eens zoveel uit, of dit nu mp3's zijn, foto's (jpg), installers, of office documenten, zij het dat daar de moderne systemen, met hun S-ATA schijven in principe in het voordeel moeten zijn ten opzichte van de P-ATA-133 op de oude systemen, wat echter wel gigantisch uitmaakt is het aantal bestanden, maar ook met een klein aantal, moet Vista/Win7 eerst gaan nadenken over wat hij nu eigenlijk is opgedragen te gaan doen voordat het er aan kan beginnen. Daarna is het verschil niet zo groot meer.

Of er daarbij een core voor 100% belast wordt of niet maakt eigenlijk niet uit, je kunt op dat moment gewoon niets meer doen voordat de bewerking klaar is.

Wat dat betreft had Linux (Debian 2.0, Ubuntu 4.5..Ubuntu 10.04) ook af en toe last van onverklaarbare latenties, XP had er nauwelijks last van, Win7 wel maar vooral Vista des te meer.

[AtleX]

Als een Explorer window 100% CPU gebruikt doe je iets fout. Dat gecombineerd met je rant op Windows en Windows 7 'Vista SP3' noemen brengt mij tot de conclusie dat je weinig verstand van zaken hebt. Ik vraag me dan ook af of een migratie naar Linux wel de juiste keus is, aangezien ook dat zeer zorgvuldig beheerd dient te worden.

Daarnaast heb je bij Linux veel meer invloed op de configuratie van je operating system. Dat vereist een aanzienlijke kennis van de werking van het systeem. Zoals je kunt zien kan 1 simpele instelling al het verschil betekenen tussen een amper werkende en een vloeiende gebruikerservaring.

Daarnaast ben ik erg benieuwd naar jullie verdere motivatie voor een migratie van Windows naar Linux. De kosten voor gebruikerstraining, beheer & implementatie zullen zeker het eerste jaar erg hoog zijn. Ik heb een aantal jaar terug 2 migraties bij bedrijven van zeer dichtbij gevolgd, en ondanks eerder enthousiasme werd er al vrij snel voor iig de desktops weer teruggegrepen op Windows. De compatibility met andere bedrijven en dienstverleners daalde, de productiviteit daalde en vooral de beheerskosten stegen. Daarnaast bleek het toch veel moeilijker dan vooraf gedacht om voor specialistische pakketten fatsoenlijke alternatieven te vinden. Een goed voorbeeld hiervan was bijvoorbeeld de Adobe suite.

[Reactie gewijzigd door AtleX op 23 juli 2024 12:54]

[i-chat]

wat een rant gehalte weer,

Ten eerste, je kiest linux niet omdat het gratis is want NIETS is gratis, alleen al de pc waarop je het wilt installeren kost geld, dan nog de brandbreedte die het updaten vergt kost geld en ga zo maar door.
Verder het feit dat er wordt teruggegrepen naar windows betekend naar mijn idee dat de verantwoordelijken gewoon niet genoeg kennis van zaken hadden om een goede keuze te maken.
Om het eens heel plat en ondoordacht neer te kwakken, elke mongool kan met de muis op <volgende> klikken, maar voor het beheer van een linux systeem (zelfs ubuntu) is nu eenmaal wat meer kennis nodig.

Of er goede alternatieven zijn voor adobe suite durf ik eerlijk gezegt niet te zeggen, maar ik weet dan ook niet wat er precies mee gedaan wordt, moeten er pdfjes worden gemaakt of is men bezig met flash shockwave of andere zut, bovendien ben ik geen dtp expert dus kan ik er alsnog weinig over zeggen.

maar feit blijft dat als deze 'problemen' onoverkomelijk zouden zijn, men deze wel eerder had moeten spotten, professioneel advies had kunnen inwinnen, en dat dus de stap naar linux in eerste instantie zowiso niet genomen had moeten worden.

[Sorcix]

En als je windows gebruikt hoef je die hardware en bandbreedte voor updaten niet te betalen? Als je het op OS bekijkt is linux wel degelijk gratis, want al de rest heb je op windows ook nodig.

En op ubuntu hoef je inderdaad niet op <volgende> te klikken.

[Reactie gewijzigd door Sorcix op 23 juli 2024 12:54]

[4bit]

" maar feit blijft dat als deze 'problemen' onoverkomelijk zouden zijn, men deze wel eerder had moeten spotten, professioneel advies had kunnen inwinnen, en dat dus de stap naar linux in eerste instantie zowiso niet genomen had moeten worden. "

Dit.
Snap niet dat er geen studie is gedaan om te kijken of er van benodigde pakketten wel linux varianten zijn. Kan me moeilijk voorstellen dat je zomaar opeens beslist van, hallo peeps, morgen is het hier allemaal linux, cheers.
En inderdaad, kosten/moeilijkheden zullen het eerste jaar hoger liggen, zoals bij zo goed als alle migraties.
En je moet trouwens niet alle pc's / servers omschakelen naar linux. Windows en Linux kunnen mooi in harmonie leven.

[mangahuisman]

Alsof alle applicaties en beheer alleen met next next next worden uitgevoerd........

[JPtja]

Zou wel willen weten waar je die cijfertjes vandaan haalt, weet mensen zat die er vaker last van hebben.
En nog iets anders, het is alweer met een OS-gerelateerd bericht zo dat er windows vs linux gesprekken komen, laat iedereen gewoon zelf kiezen wat ze willen en erover praten op de daarvoor bestemde fora, want explorer.exe die 100% draait en dat dat wel of niet een bug is heeft volgens mij niet zo heel veel meer te maken met het eigenlijke bericht..

[Reactie gewijzigd door JPtja op 23 juli 2024 12:54]

[BeosBeing]

Iedereen gebruikt het systeem anders, de ene start zijn programma, klikt op file/open en zoekt dan zijn bestand op, de volgende opent een explorer-venster, zoekt zijn bestand op en dubbelklikt, de derde gebruikt daar altijd rechtsklik en de vierde gebruikt altijd het menu bovenin. Doet één van de vier iets fout, nee dat kun je niet stellen, is de ene methode efficiënter als de andere, ja, maar dat is ook gebonden aan voorkeur, wat de ene handig vind, is voor de andere onwerkbaar. De ene opent het bestand vanuit zijn app, omdat hij dan alleen de bestanden te zien krijgt die hij wil, de andere vind het venster dan te klein (en vindt dat iedere keer groter makken niet handig, doet dat liever één keer) en heeft in explorer het overzicht over al zijn bestanden.

Bij de drie die hier het explorer venster gebruiken, kan heeft de ene dat venster altijd op lijst staan, want dan kan hij het grootste aantal bestanden zien, de volgende heeft liever grote pictogrammen en bij de derde (o.a. mij) staat die op detaïls zodat hij de bestandsdata kan zien, de bestandgrootte en eventueel nog andere eigenschappen.

Dat zijn alles bij elkaar al 10 verschillende mogelijke werkwijzes en als een bug slechts bij één van die 10 zal optreden zal dus het merendeel van de gebruikers die bug niet opmerken. Tel daarbij het aantal verschillende hardwarecombinaties op en het aantal slachtoffers wereldwijd zakt tot op niveau's van minder dan ¼ promile en daarvan zullen de meesten niet eens een bugreport insturen maar enkel klagen als het ze voor de zoveelste keer overkomt en ze er dus door gefrusteerd raken.

[postbus51]

Dat zijn alles bij elkaar al 10 verschillende mogelijke werkwijzes en als een bug slechts bij één van die 10 zal optreden zal dus het merendeel van de gebruikers die bug niet opmerken.

Idd en dan hebben we het nog niet eens over welke software er nog meer draait (bg)
Anders was er wel een algemene terugroep (lees patching) zoals in de autoindustrie
waar het niet uit maakt of je nou wel of niet de radio op freq 538 hebt en de remmen weigeren

[Verwijderd]

Zo goed huilebalkjes?

Ik weet niet helemaal wat je probleem is, afgezien van het OS probleem dus, maar, misschien dat je je houding enigszins moet bijstellen.

Dat jij problemen hebt met een besturingssysteem maakt dat besturingssysteem niet in één klap waardeloos.

Voor iemand die naar eigen zeggen erg veel verstand van zaken heeft maak je je er wel met een jantje-van-leiden vanaf. Niet eens proberen het probleem op te lossen door het daadwerkelijk op te lossen. Nee, je gaat het probleem gewoon volledig uit de weg door maar over te stappen op een ander OS, dat weer een gehele reeks aan andere problemen en uitdagingen met zich mee zal brengen.

En dàt kan ik je garanderen.

[Meekoh]

Relax man!
Geen 1 OS is heilig. Wij zijn hier ook tegen genoeg bugs aangelopen in Linux/Unix.
Net zoals die er ook in Windows zitten.
Echter Indien het een bug is in Windows en Microsoft het erkent heeft, heb je daar dan ook een KB artikel van? Ben er wel geïnteresseerd in.
D
Linux is ook geen walhalla Ieder OS heeft zo zijn rare trekjes...

[elteck]

Ja op zich wel, maar deze "group scheduler" groepeert ze per "VT" dus eigenlijk krijgen alle gebruikers programmas nu hogere prioriteit, ook die compiler. Alleen dit gaat ten kosten van de systeem processen. Voor desktop gebruik is dat prima, de vraag is bijvoorbeeld, gaat de netwerk doorvoer nu niet trager?
Dit gaat vast een kernel optie worden die ze niet voor servers gebruiken.

Voor diegene die beweren dat Linux traag zou zijn, een paar linkjes:

Zie hier:
http://www.computerworldu...d-trade-speed-with-linux/

http://www.networkworld.c...aflop-barrier-loses-top-5

Voor gebruikers bijkt grafisch dat Linux opengl trager is dan Windows directX, op game gebied wint Windows alle benchmarks. Maar zodra het op data troughput aankomt en rekenkracht, loopt Windows ver achter. Hier een mooi overzicht:

http://www.phoronix.com/s...item=ubuntu_win7_ws&num=1

Kortom, Windows is meer geoptimalizeerd voor games.

[H!GHGuY]

networking draait grotendeels in de soft interrupt daemon en die heeft Real-Time prioriteit.

[Aetje]

Het verbetert de responstijd door taken beter parallel uit te voeren. Een verbetering in de desktop experience is voor een systeem voor end users zeer nuttig.

[MrSnowflake]

Idd, de terminal vensters worden gebruikt om de kernel te compileren. Dat had de editor best mogen zeggen. Zonder de kernel te compilen zou het systeem niet bepaald hard op de proef gesteld worden.

[ooowyeah]

Dat wordt ook niet geclaimd wel zou de gebruikers ervaring beter worden. En dat is ook precies wat deze patch bewerkstelligt dus dat is mooi Vooral bij de desktop versies van Linux of dezelfde afweging geldt voor "buildservers" oid lijkt me niet daar ligt de prioriteit op performance van de processen en niet op gebruikers ervaring.

[g4wx3]

Dit is wel belangrijk!

Dit is de reden dat BeOS zo revolutionair was in de Jaren 90 tot dat xp uitkwam in 2001
Dit is ook wat wordt gewaardeerd aan Mac OS X.
Apple users zijn absoluut niet gewend om te wachten op een taak, worden ze al gek als ze een strandbal zien. (niet perse een BBOD).

Dit is ook heel belangrijk op smartphones. Alles op het scherm moet vloeiend gaan. Achtergrond taken moet in wacht gezet kunnen worden.

[BeosBeing]

Hopelijk is dat iets dat ook de makers van Haiku voor elkaar krijgen. Dat maakte o.a. ook dat in BeOS video's en muziek toen al vloeiend draaiden waar een veel krachtiger Windows-Systeem dat niet voor elkaar kreeg. Je kon met een Pentium II waar windows aan een Pentium 4 nog niet genoeg had.

Het was samen met het Be-bestandssysteem zijn de twee belangerijkste vernieuwingen van BeOS. Microsoft heeft geprobeerd om sommige eigenschappen van het Be-Filesystem geprobeerd te kopiëren in NTFS dat nu bepaalde eigenschappen kan weergeven als album, artiest, afmetingen, bitrate, brandpuntsafstand, breedte, hoogte, formaat, maar het eerste verschil is dat dit bij NTFS een vaste lijst is waarvan de meeste niet gebruikt worden, waardoor je, als je ze wilt tonen, de hele lijst moet doorlopen.

[sniek]

Subjectiviteit kent geen tijd!

[ontopic]
Ziet er indrukwekkend uit. Ik vraag me echter af welke zware werklasten dan worden gescheiden? Heeft iemand hier inzicht in? Ik start mijn iets zwaardere shell scripts sowieso in een andere TTY...
[/ontopic]

[Ruud Koot]

Wat het artikel niet vermeld is dat op de achtergrond 64 compilers, gestart vanuit één console, draaien die voor een zware systeem last zorgen. Als je nu 64 compilers draait en één interactief process, zoals een webbroweser krijgen ze allemaal 1/65e deel van de CPU tijd toegewezen. Met de patch krijgt de browser 1/2e deel en de compiler processen allemaal 1/128e.

Dit zorgt ervoor dat de "interactiviteit" met een factor 10 toeneemt. Reageerde de browser eerst pas na een seconde op een muisklik, zal hij dit nu al binnen 1/10 seconde doen. De compilatie op de achtergrond zal echter wat langer duren, en zeker niet 10 maal zo snel verlopen.

[Countess]

Met de patch krijgt de browser 1/2e deel en de compiler processen allemaal 1/128e.

ik denk dat dat iets te cru is uitgelegd.
het is vooral dat interactive taken prioritijd krijgen, dus mochten ze extra cpu nodig hebben dan krijgen ze die eerst. hebben ze die niet nodig, dan krijgen de compilers die extra kracht weer.
het compileren duurt dus niet 2 keer zo lang.

in theorie hoeft het zelfs niet langer te duren, alles dat de desktop user wil doen moet toch gebeuren, nu gebeurt het alleen meteen ipv dat hij er lang op moet wachten (los van het feit dat hij meer zal willen doen als zijn desktop goed reageert natuurlijk, maar dat is de menselijke aard)

[johnkeates]

Automatisch renicen was er al.

[sniek]

Ruud, geweldig uitgelegd. Zelfs ik begrijp het.

10 keer zo snel hoeft van mij ook niet, even snel en 10 x zo responsive is al meer dan voldoende!

[Xirt]

Ik moet eerlijk bekennen dat Linux hier een stuk sneller is dan het (in miijn ogen) lompere Windows. De boot tijd is fantastisch (vanaf de bios iets van tien seconden tegenover een halve minuut (minstens) voor Windows 7) en alles draait vloeiend (met Compiz aan). Het enige dat 'out-of-the-box' bij mij niet lekker vloeiend draaide waren video's, maar dit bleek aan de video-software te liggen die met Ubuntu meegeleverd werd. Pas bij zware taken krijg ik last van haperingen, maar onder Windows is dat nog iets erger. Ik kan het dan ook alleen maar toejuichen dat deze patch het multitasken nog prettiger maakt =).

[Brupje]

halve minuut voor Windows 7? Tot het login scherm misschien. Op de systemen waar ik het heb draaien gaat hij na het login scherm vrolijk nog een paar minuten verder totdat het systeem lekker werkt.

[YopY]

Wat voor software wordt er dan nog onder je eigen account opgestart? Virusscanners, IM clients etc, neem ik aan? Meestal worden er onder Linux standaard miner programma's gelijk opgestart (en mogelijk nemen die niet gelijk je hele I/O over, zoals dat wel het geval is bij Windows programma's die gemiddeld een hoger meukgehalte hebben).

[Niosus]

Bij mijn Ubuntu start al die rommel niet meteen op omdat als ik er op klik het toch start binnen de paar seconden. Bij windows "ff" msn open doen duurt vreselijk lang vergeleken met de meer slim&lite empathy. Hetzelfde geldt voor bijv de file browser, hoe vaak ik wel niet klik om pas 10 seconden later het daadwerkelijke venster te zien.

Ik denk trouwens ook dat het idee dat alles mee moet opstarten met het OS achterhaald is. Als ik wil sociaal doen zou ik wel willen dat mijn chat client vanzelf start, maar als ik iets gedaan wil krijgen weer niet. Ook dingen zoals tools om iso's te mounten... waarom kunnen die niet gewoon starten wanneer ik daadwerkelijk een iso wil mounten ipv een vies icoontje op mijn balk te dumpen. Of al die updaters?
De omgeving blijft veel lichter als alles gewoon start wanneer het echt nodig is. En het werkt ook beter. Wie kent het fenomeen niet wanneer je de oude windows xp van een kennis opzet voor onderhoud en je krijgt 10 meldingen voor updates, volledige versies aan te kopen en een of ander programma dat altijd crasht bij het opstarten? Als ik mijn mail wil checken doe ik chromium op en ik klik op de bladwijzer van gmail... wil ik helemaal niet dat die halve stalker mij online ziet komen en mij begint vol te spammen.

[compufreak88]

Dat jij dat niet wil, wil nog niet zeggen dat anderen dat ook niet willen.

In veel programma's is het een optie om automatisch op te starten met Windows, maar die kun je ook uitzetten.

[BeosBeing]

De meeste apps hebben die optie niet hoor, en ik zou hem graag willen, zelfs voor Explorer (ik heb genoeg andere bestandsmanagers op mijn HD staan (vooral installers want ik gebruik er hooguit 2, PeaZip niet meegerekend)

[Jerie]

OS X launchd start allerlei programmas parallel en het Linux alternatief systemd, de opvolger van Upstart, doet iets soortgelijks.

Windows daarentegen start nog allerlei programmas en services op wanneer je inlogt. Bij Linux (GNOME, KDE) en Mac OS X is dat stukken minder. Het gevolg is dat je bij Linux en Mac OS X inderdaad direct allerlei programmas kunt gebruiken die CPU tijd en I/O gebruiken danwel misbruiken terwijl dat bij Windows nog niet kan. Die moet eerst uitratelen. Ook maakt het het vergelijken van opstarttijden lastiger. Dat ken je misschien nog van Microsoft Internet Explorer: ja, die start sneller op dan Mozilla Firefox, omdat allerlei libraries die MSIE gebruikt (zoals MSHTML) al zijn geladen tijdens het booten van Microsoft Windows. Sloop je dat er uit (je gebruikt bijvoorbeeld LiteStep) dan zul je zien dat Mozilla Firefox vele malen sneller start. Althans, zo was dat een aantal jaar geleden het geval bij MSIE 6.x.

[BeosBeing]

Toch litestep nog maar eens proberen dus. IE gebruik ik zowiezo niet. Installeer eerst alle software vanaf usbdrive en pas dan gaat de netwerk-kabel er in.

[erikdenv]

Precies, ik draai ze allebei in dual boot. Als ik wil Starcraften start ik Windows op, log in en laat hem dan even uitrazen anders zit ik me maar te ergeren tijdens Starcraft.

[teek2]

Linux niet snel? Beetje rare opmerking, bedoel je dan Kernel benchmarks?

Ik hoop niet dat je distributies of desktop omgevingen bedoelt want het slaat nergens op om op basis daarvan te zeggen "Linux vond ik nooit zo snel".
Hooguit bedoel je Ubuntu met Gnome is niet zo snel in vergelijking met Windows 7 of osX bijvoorbeeld. Draai maar eens openbox en dan met je het omgekeerde ineens concluderen.

Je opmerking zegt in ieder geval niets over waar dit artikel over gaat.

[Dj Neo Ziggy]

op welke kernel is dit? even of oneven?

[moto-moi]

sinds 2.6 is er geen onstabiele tree meer, er wordt gewoon ontwikkeld in 2.6.X, deze patch is getest op 2.6.37-rc1.

[Wirf]

Ik heb deze patch geprobeerd uit te proberen, maar ik kon hem alleen werkend krijgen door de GIT tree van Linus direct te clonen en daar de patch over te draaien.

Ik kwam de volgende problemen tegen namelijk:

- 2.6.37-rc2 heeft een bug mbt. PCI mmap waardoor de grafische omgeving (Xorg) niet meer werkt
- 2.6.37-rc1 mist een file die deze patch probeert te patchen

Dus dit is misschien ook voor belang voor iedereen die deze patch wil proberen.

Ik deed dit:

[code]
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6
patch -p1 < interactive_patch.patch #of hoe je deze patch ook hebt opgeslagen
make oldconfig
make -j4 bzImage modules && make modules_install
[/code]

Succes, iedereen die het wil proberen!

[litemotiv]

Hier ook een versie voor 2.6.36: http://pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2

(op eigen risico uiteraard)

[Verwijderd]

Gezien het nog niet in de 'mainstream' zit is het op de oneven kernel.

[Freeaqingme]

Dit komt in 2.6.38:

This patch truly does wonders to the Linux kernel in improving the desktop responsiveness / interactivity. This patch with improving his web-browsing experience and more, impresses even Linus Torvalds. The merge window is now closed for the Linux 2.6.37 kernel, but this should be an exciting improvement that should be found in the Linux 2.6.38 kernel and at least keep the people happy waiting around for Reiser4 / Open-Source VIA Graphics / Radeon HD 6000 Series DRM to arrive in the mainline kernel.

http://www.phoronix.com/s...em=linux_2637_video&num=2

[servies]

Dat wordt al heel lang niet meer gebruikt...

[breezie]

vreemd dat je met 200 lijnen code zo sterk kunt optimaliseren
nog vreemder is dat niemand hier eerder aan gedacht heeft?

[Umbrah]

Nou ja, afhankelijk van uiteraard wát voor code (gok dat het hier om C gaat), wil aantal regels niet eens zo veel zeggen, zeker als je je realiseert dat dit alleen om "groupen" gaat van iets wat al bestaat, dat zie je ook aan het feit dat 9 coderegels weg moeten, iets zegt me dat die negen de standaard 'bulk objecten op' code is, en er in plaats daarvan een functie is ontstaan waarbij de code opgedeeld wordt in groepen.

Het is niet zo vreemd dat niemand hier aan gedacht heeft gezien de aard van het systeem: het is dusdanig specialistisch en kritiek voor de kernel dat eigenlijk niemand er ooit naar kijkt (al was het maar uit angst dat ze het verknoeien, een monolitische kernel kan tricky zijn). Dat dé expert van het product zelf, Torvalds, er mee komt zal me dus ook niet verbazen, uiteindelijk is HIJ het ook die de main branche van de kernel beheert.

[Verwijderd]

Nou ja, afhankelijk van uiteraard wát voor code (gok dat het hier om C gaat)

De kernel is een mixture van C, C++ en assembly. In het geval van C++ gaat het erom dat stukken C++ code gebruikt kan worden in C mits je de juiste declaraties en juiste manier van compileren gebruikt. Assembly wordt weer gebruikt om bepaalde stukken sneller te maken wat in C en C++ nooit gelukt zou hebben.

[Belboer]

Het is alleen C en assembly. C++ wordt niet in de kernel gebruikt. Zie de uitleg hier http://www.kernel.org/pub/linux/docs/lkml/#s15-3.

[kidde]

Sinds recentelijk, en dan hebben we het echt over 'niet langer dan drie maanden', is C++ wél in de kernel toegelaten, mits men niet gebruikt maakt van de 'meest complexe' C++-ideeën.

[H!GHGuY]

Daar wil ik wel eens een bron van zien.
De dag dat C++ toegelaten wordt in de Linux kernel (op de mainline) ligt HEEL ver in de toekomst.

[ACM]

Het is gewoon beter gebruik maken van reeds bestaande functionaliteit, als ik het goed zie. De mogelijkheid om groepen applicaties te schedulen zat al in de kernel. Er is voor zover ik het begrijp vooral een extra/andere vorm van groepering toegevoegd.

De reden waarom het niet eerder gedaan is, is wellicht omdat het een nogal belangrijk stuk code is. Waar je niet zomaar van alles en nog wat aan gaat lopen sleutelen.

[CAPSLOCK2000]

Als je wilt groeperen dan moet je een criterium hebben. Bijvoorbeeld alles van 1 gebruiker in 1 groep. Of alles op het linker scherm in 1 groep. Of ieder proces zijn eigen groep. Of alle multimedia applicaties in 1 groep. Mogelijkheden zat. Er is nu weer een nieuw criterium bedacht, en dat lijkt vrij aardig te werken in desktopsituaties.

[SLipEdd]

Dat is meestal zo hé. Geniale ideeën zijn later meestal simpel, maar je moet er maar op komen
Als iedereen overal al aan had gedacht, wat een saaie wereld zou het dan zijn

[GiLuX]

het is enkel het anders verdelen van de load.
hoeft niet heel veel code te zijn.

is vast wel eens aan gedacht maar nu pas echt nodig omdat je nu echt verschil ziet als je zware taken uitvoert als hoge resolutie filmpjes decoden en tegelijkertijd ook veel andere zware processen draaien.

en blijkbaar durfde men het vroeger niet aan maar nu er echt winst was te behalen was dat risico het wel waard blijkbaar.
en zie daar...

ben benieuwd wanneer dit in een stable kernel terecht gaat komen...

[Reactie gewijzigd door GiLuX op 23 juli 2024 12:54]

[revertive]

Het is niet zo dat linux opeens sneller word, het word alleen sneller voor het gevoel. Het is nu zo dat achtergrond taken alle resources kan gebruiken en daardoor de webbrowser op de voorgrond minder resources heeft en langer lijkt. Nu word de last anders verdeelt, voorgrond processen krijgen de resources die ze nodig hebben om vloeiend te draaien, en daar door zullen andere processen langzamer zijn.

[Jerie]

vreemd dat je met 200 lijnen code zo sterk kunt optimaliseren

Ja, en met 1 regel code kun je boel laten crashen, of een backdoor inbouwen.

nog vreemder is dat niemand hier eerder aan gedacht heeft?

Dat zei de uitvinder van het buskruit of het wiel ook.

[freaq]

wow dat is een serieus verschil!!!!

gaat dan de performance bij bijvoorbeeld renderen ook omhoog,
of dat niet? aangezien die dingen meestal al vrij optimized zijn, maar als de kernel wordt geoptimaliseerd worden die programma's dan ook sneller net als deze browsers?

[ACM]

Nee, eerder omlaag. Het is niet alsof er nu ineens grote hoeveelheden extra cpu-kracht beschikbaar is. Maar wel zo dat de verdeling van de load meer geschikt is voor desktopsystemen, ongeacht of een achtergrond-taak dan veel rekenwerk nodig heeft zal bijvoorbeeld een desktopapplicatie vlotter kunnen reageren.

[daft_dutch]

Ja tuurlijk zou de performance van de achtergrond processen theoretisch omlaag gaan. Maar het is niet dat er CPU cycles verdwijnen. De browser is eerder klaar met het verwerken dus kan het achtergrond process ook weer eerder 100% cpu pakken.

[MSalters]

Eh, dit soort schedulers laten wel degelijk CPU cycles verdwijnen in de praktijk. Beter gezegd, er is altijd een trade-off tussen efficiency (zoveel mogelijk CPU cycles gebruiken) en responsiveness (zorgen dat de user interface snel genoeg z'n CPU cycles krijgt).

Het meest simpele voorbeeld is een scheduler die altijd een core vrijhoudt voor de UI. 100% responsive, maar de efficiency op een dual-core is beperkt op ~50%.

[H!GHGuY]

Euh, nee?

De enige cycles die verdwijnen zijn die die opgaan in task/context switching en die die de scheduler nodig heeft om te kiezen welke taak nu het best loopt. Verder gaat er geen enkele cycle verloren.

[servies]

Nee, de 'performance' zal er waarschijnlijk niet echt van verbeteren, het zal echter wel zo lijken. Het is de rekenkracht die efficiënter en beter verdeeld wordt...
Ik vermoed dat de aanpassing zodanig is dat de kernel taken automatisch herkent/classificeert zodanig dat interactieve taken (dat wat een gebruiker echt ziet/merkt) meer processor toegewezen krijgt dan bijvoorbeeld een niet interactieve taak...
Heel erg versimpeld:
Met de originele kernel (zonder deze patch) zou het compileren van een groot software project een uur duren. De video die je tegelijkertijd bekijkt is dan schokkerig.
Met de patch zal het compileren nu een uur en 5 minuten duren, de video is nu echter zonder schokken te bekijken.

[fevenhuis]

Nou de desktop performance verbeterd dus wel degelijk en dit is eigenlijk zoals de zaken natuurlijk horen te werken met meerdere cores. De gebruiker moet gewoon rekenintensieve taken kunnen opstarten zonder dat het hele systeem erdoor word lam gelegd.

[citruspers]

Volgens mij gaat het hier meer om het uitvoeren van "paralelle" taken (onder 1 kern), dus ik denk niet dat je er veel snelheidswinst mee boekt als je CPU al verzadigd is. Wel kan je nu wat anders doen tijdens de render zonder dat het al te veel gaat stotteren.

Keertje proberen op een LAN party?

[Umbrah]

Ik vraag me af wat dit betekend voor "Linux based" systemen als Android...

(en de compleet ongerelateerde unix-achtigen als BSD's en MacOS 10)

[Reactie gewijzigd door Umbrah op 23 juli 2024 12:54]

[Adion]

Vermits dit voornamelijk invloed lijkt te hebben op de prioriteit die verschillende programma's krijgen lijkt het mij voor smartphones in het algemeen minder effect te zullen hebben. Daar zal je denk ik zelden zware taken op de achtergrond hebben lopen, dus de beschikbare processortijd kan al zo goed als volledig door de interface gebruikt worden.

[johnbetonschaar]

Ik vraag me af wat dit betekend voor "Linux based" systemen als Android...

Helemaal niks. Android start geen tientallen processen tegelijk op in tty's, en de multitasking en scheduling van Android applicaties zelf is waarschijnlijk volledig in de Java VM geimplementeerd en niet op kernel niveau.

[compufreak88]

Maar is het niet zo dat Java het weer aan de kernel delegeert?

[MSalters]

Weinig. Torvalds heeft heel lang dwarsgelegen bij de ontwikkeling van bruikbare schedulers en de voorkeur gegeven aan exotische schedulers. Zie bijv http://xkcd.com/619/.

Ondertussen waren buiten de "officiele" branch al lang betere schedulers beschikbaar, die optimaal zijn voor gewone hardware. Torvalds weigert die te integreren, omdat hun single-core performance ten koste gaat van de 128-core performance. De eerste 128-core smartphone moet nog gemaakt worden, dus elke verstandige smartphone ontwikkelaar laat Torvalds officiele schedulers links liggen

[Jerie]

Weinig. Torvalds heeft heel lang dwarsgelegen bij de ontwikkeling van bruikbare schedulers en de voorkeur gegeven aan exotische schedulers. Zie bijv http://xkcd.com/619/.

Ondertussen waren buiten de "officiele" branch al lang betere schedulers beschikbaar, die optimaal zijn voor gewone hardware. Torvalds weigert die te integreren, omdat hun single-core performance ten koste gaat van de 128-core performance. De eerste 128-core smartphone moet nog gemaakt worden, dus elke verstandige smartphone ontwikkelaar laat Torvalds officiele schedulers links liggen

Och gut, weer zo'n CK freak? Nadat CFS zodanig doorontwikkelt was dat het ook op desktops een prima performance geeft in vergelijking met bijvoorbeeld BFS doet CFS niet meer onder tov BFS. IIRC is dat de versie in Linux kernel 2.3.32.

Kijk je naar bijvoorbeeld Maemo dan gebruikt deze een iets oudere Linux kernel, en kun je dus 3 dingen doen: 1) zo laten (niet ideaal voor performance, maar wel de officiele ondersteunde versie), 2) je patched BFS (dat is gedaan door iemand; zie Maemo forums; overigens zag ik de laatste keer dat ik hierover las geen benchmarks) 3) je backport CFS (da's nogal wat werk en vereist expertise).

Er zijn overigens diverse 'hacks' om je Maemo meer 'snappy'/responsive te maken. De een is nog eenvoudiger te installeren dan de ander. Bijvoorbeeld VM swappiness of Hilden Desktop config even aanpassen.

Hoewel je geen kernels gaat compileren op je Nokia N900 heeft 't systeem soms wel wat load. Als er load is dan wil je toch dat de UI snappy blijft. Deze patch verbetert dat tov huidige CFS en is dus van harte aan te raden. Ook Android, webOS zullen profiteren van deze patch. Als ik het goed heb begrepen leunt het niet specifiek op Xorg.

[MSalters]

Ehm, ik heb het niet over desktops (die hebben vaak zat 4 cores, en best dikke) maar over smartphones (1 ARM, haalt meestal de Ghz niet). Desktops lijken feitelijk meer op servers dan op smartphones, en ik geloof daar nog wel dat CFS mee kan komen. Maar op een 200 Mhz ARM device met 32 Mhz geheugen? Dan wil je een scheduler die goed is om 4-8 runnable threads te managen.

[H!GHGuY]

Dan wil je een scheduler met de PREEMPT_RT patches zodat je belangrijke taken altijd eerst lopen.
Bovendien is de scheduler een tool met input en output. Als je je prioriteiten (nice/RT prio) niet goed kiest, moet je geen goeie responsiveness verwachten ook. Of denk je dat windows 7 op een P3 800MHz beter draait?

De Linux task scheduler en I/O schedulers zijn stukken beter dan gelijk wat MS ooit heeft uitgebracht (en dat is een mening, geen feit).

[Nienix]

maemo en meego niet te vergeten

[Junky]

wow... thats a hell of a code writer dan zeg zoveel ervaring met linux heb ik niet maar dit is toch wel erg knap, petje af

[hiostu]

Het is meer prio geven aan user gerelateerde processen. De andere processen zullen dus langzamer werken. Het is niet zo dat alles ineens sneller gaat.

[Xirt]

De gebruiker zal echter ervaren dat alles sneller lijkt te lopen wat het uiteindelijke oordeel over Linux zal verbeteren.

[YopY]

En dan vraag ik me af waarom ze deze (relatief kleine / eenvoudige wijziging, voor zover een leek als ik dat kan beoordelen) wijziging niet eerder doorgevoerd hebben.

[kidde]

Dat stuitte altijd op weerstand van Linus hemzelf, die de boel 'vetoode' met NEE. (zie m'n reactie hierboven).

[Reactie gewijzigd door kidde op 23 juli 2024 12:54]

[ronansoleste]

misschien was dat omdat linus daar redenen toe had?.... hij is niet tegen de desktop zoals jij suggereert in je eerdere opmerking. hij is wel tegen slechte/knullige code en daar is hij vrij hard in.

[Verwijderd]

CPU power is vandaag de dag niet meer zo'n issue en Linux wordt niet meer alleen op verouderde systemen gedraaid en wordt populairder op nieuwe systemen.

CPU is er zo plenty dat het opzich in overall niet trager wordt... dat moet duidelijk een reden zijn.

CPU is er over het algemeen voldoende, I/O is de issue... dus kun je best wat CPU snoepen voor wat visuele zaken

[BeosBeing]

CPU power is nog steeds een issue. Je wilt immers je moderne software (waar de meeste bekende lekken in zijn gedicht) ook draaien op je oudere hardware. Het simpele feit dat software steeds zwaarder wordt, deels door patches die altijd groter zijn als de code die er eerst stond, anderzijds door het steeds toevoegen van nieuwe features, maakt dat dat op een gegeven moement niet meer gaat. Daarbij gaat hardware ook wel eens kapot (vooral als je het niet meer gebruikt en op zolder zet) en onderdelen vervangen is verhoudingsgewijs duurder als iets nieuws kopen dat ook nog sneller/beter is.

Ik ben op dit moment een PC opnieuw aan het installeren, dat ding is mischien wel 10 jaar oud, duron 850-systeem met 768MB ram. En dat ding gaat dus 3 keer zo snel zijn als de PC (Pentium II, 300Mhz, 256MB ram) die men daar nu gebruikt en totaal niet meer responsive is met sp3 van XP (sp1 ging nog prima). Maar uiteraard is dat een uitzondering, de meeste mensen zullen een nieuwer systeem hebben als dat.

Ook websites worden steeds zwaarder, schermresoluties groter, cameraresoluties hoger, harddisks groter, dus bitrates hoger. Dat loopt allemaal via I/O maar moet ook verwerkt worden door de cpu.

En eigenlijk willen we al die power (van bijvoorbeeld een hexacore Phenom II of een Core i7) ook nog eens mobiel gebruiken, opvouwen en in de binnenzak meenemen in het vliegtuig, op de bank lezen als eentijdsschrift (A4) of tabloid en op het werk een lekker groot fullhd-scherm van 22" of groter, of zelfs twee zodat je er een fatsoenlijke spreadsheet op kwijt kan, overzicht hebt over alle 200 velden van je database-query of twee boekhoudingen naast elkaar kunt zetten om te vergelijken. En mobiel kost al die cpu-kracht batterijcapaciteit en dat is nou net het zwaarste onderdeel van de tablet/notebook/... en wat willen we niet teveel meenemen? Juist, gewicht.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 12:54]

[Verwijderd]

Dat is zeer goed nieuws. Een factor 10 is wel enorm.

Ben benieuwd wanneer deze in de mainstream distro's wordt opgenomen danwel als extra kernel worden aangeboden.
Kernel hacking is nog altijd niet voor iedereen 'a piece of cake'

Denk dat ik vanavond heerlijk aan de kernel patching ga zitten

[LuitvD]

Deze patch komt in 'mainline', wat dus betekent dat het vanaf de volgende kernel-versie standaard ingebakken zit, en je 'm automatisch dus in distro's terug ziet die deze (of een nieuwere) kernel gebruiken. Waarschijnlijk zal Ubuntu er voor zorgen dat deze patch ge-backport wordt naar hun kernel als ze nog een oudere versie blijven gebruiken in bijvoorbeeld hun 10.04 en 10.10 versie. (geen garanties, slechts speculatie!)

[Verwijderd]

Ja hij komt dus pas in 2.6.37 terecht, en 2.6.26 heeft nog geen final release. Voordat ie in een ongepatchte final release kernel zit duurt het dus nog wel even..

Ubuntu zal m waarschijnlijk wel sneller backporten inderdaad.

[erikdenv]

2.6.26 heeft geen final release, hoe bedoel je? Bedoelde je misschien 2.6.36?

[smspvdm1]

2.6.36 heeft wel een final release http://kernel.org/

[citruspers]

Dit is iets waar ik al een tijdje op wachtte, op mijn laptop draaide Ubuntu nooit meer zo vloeiend als ik zware taken als virtualisatie deed, ondanks dat de CPU niet volledig belast werd. De hardeschijf vervangen door een SSD hielp al een hoop maar toch bottleneckte er nog iets. Dit lost deze patch dus gedeeltelijk op, heerlijk!

[ACM]

Voor zware I/O-achtergrond taken kan je overigens ook al wat doen met 'ionice' (en visualisatie 'iotop'). Dat zorgt er bij mij iig voor dat het starten van een backup (zo snel mogelijk de data lezen) op de achtergrond bij het bekijken van een film (stabiele stroom data nodig) een stuk beter gaat.
Wellicht dat deze patch ook nog het cpu-aandeel wat zou verbeteren (gpu doet al het gros van het decodeerwerk).

[citruspers]

Bedankt, dat kende ik nog niet (al heeft mijn SSD het I/O probleem grotendeels opgelost).