Torvalds: Ingen slankekur til overvægtig Linux-kerne

Hvis ydelsen er faldet 2 procentpoint over 10 releases, så er ydelsen altså faldet til 0.98^10 = 81.71%, altså et fald på godt 18%...
For at få et total fald på 12%, så er ydelsen "kun" faldet med 1.27% pr. release.

Og hvad der er det rigtige, prøver jeg nu at undersøge nærmere, for der er vist noget i The Registers oplysninger, der ikke stemmer. Tak til Martin for at påpege det.

Mvh Mikkel, v2.dk

Det fremgår ikke hvad der egentligt er blevet benchmarket og jeg vil påstå at en generel påstand om at kernen er blevet X% langsommere er noget sludder.

Man kan garanteret komme frem til den slags resultater hvis man kigger på noget meget specifikt som f.eks. icache misses, men så ser man samtidigt totalt bort fra forbedrede algoritmer der undgår skrivninger til storage devices, bedre caching osv.

Det virker som en ret syntetisk og ligegyldig benchmark umiddelbart, men det er selvfølgelig fint hvis det kan provokerer nogle folk til at kigge nærmere på performance i de forskellige subsystemer.

Instruktionscachen burde kun fyldes med kode, der faktisk udføres, så et større Icache forbrug er vel ikke kun et symptom på en unødvendig stor kerne, men også et udtryk for at brugerne lader deres kerner understøtte mere forskellig hardware?

Angående selv kernens størrelse, og effektiviteten af den, så bygger Gentoo folkene deres Linux kerne på den maskine, hvor den skal køre.

Hvis man kigger på sådan en kerne (som er sat op til kun at understøtte den hw, der faktisk er til stede, og oversat med CPU specifikke flag), hvor meget vil det så (typisk) mindske kernens størrelse, og hvor meget vil det typisk øge dens hastighed?

Kernens størrelse kan begrænses ret pænt, men det gør ikke nogen mærkbar forskel i hastighed.

Hvilket egentligt er ganske logisk.. Den nødvendige kode er der jo stadig og skal stadig udføres, så den vil stadig ramme instruktionscachen. Omvendt så vil den "unødvendige" kode ikke ramme instruktionscachen i hverken den fulde eller den minimale kerne.

Det der kan give lidt bedre performance i nogle områder af kernen er at man kan compile den til en given processor version og dermed udnytte nogle af de nyere instruktioner som ikke bliver brugt i en generisk kerne. Igen vil det dog være meget minimalt hvad der er af forskel.

Jeg har i mange år brugt både kerner jeg selv har compilet og distributions kerner (typisk fra Debian eller Ubuntu) og jeg har aldrig bemærket nogen videre forskel.

citat:"Angående selv kernens størrelse, og effektiviteten af den, så bygger Gentoo folkene deres Linux kerne på den maskine, hvor den skal køre.

Hvis man kigger på sådan en kerne (som er sat op til kun at understøtte den hw, der faktisk er til stede, og oversat med CPU specifikke flag), hvor meget vil det så (typisk) mindske kernens størrelse, og hvor meget vil det typisk øge dens hastighed?"

Mine erfaringer med tilpassede Linux kerner giver Bryan Østergaard ret i at størrelse på kernen bliver markant mindre, mens performace ikke ændrer sig særlig meget. Performace for en server har jeg dog kunnet fin-tune til 30% ekstra med processor specifikke kompileringsparametre, kompilere kerne-moduler ind i kernen, og rydde op i userspace. (Der er ikke installeret software jeg ikke skal bruge - det gælder også device drivers.)

Jeg tror vi i fremtiden vil se Microkernel og Exokernel operativsystemer, med langt mindre kerne - og at de vil udvikle sig til at være mere fleksible, og have større sikkerhed, end Linux.

Ved at lave kernen minimal, og sikre programmer og processer er indkapslet og sikker, så opnås at drivere der ikke er del af operativsystemet, ikke kan ødelægge noget, og kun kan medføre at de selv ikke fungerer.

Linux og Unix er sikkerhedsmæssigt noget forældet. Det er fra før at sikkerhed reelt blev et problem. Dengang, var sikkerheden baseret på brugere, som blev adskildt fra hinanden, og det var heri det store sikkerhedskoncept lå. Siden, har vi haft problemer med programmer der ikke har været sikre, og ikke bare brugere. Det betyder, at såvel programmer, som drivere, skal indskapsles og anbringes i et sikkert system.

Det medfører også, at selve operativsystemet bliver mindre, da så meget som muligt lægges ud på drivere og programmer, af hensyn til sikkerheden.

Ofte vil det endvidere medføre større overblik. Du vil kunne få et overblik over kernen, uden at skulle sætte dig ind i stor overflødig kode. De udvidelser som kommer, er ikke til kernen - for den udvides ikke. Udvidelserne kommer i form af nye drivere og programmer, og eventuelt andre former for plugins, som er "lukket inde" og isoleret, så de intet kan ødelægge. Er der fejl, vil selv brugeren kunne identificere den pågældende driver, program, eller anden form for plugin, og det er kun nødvendigt at finde fejl i den pågældende kode. Det er altid vigtigt, at udvikle operativsystemet, så brugeren har nem ved at se hvor fejlen foremkommer. Er det f.eks. printeren, som ikke vil skrive ud, er det naturligvis printer softwaren som fejler - og ikke scanner, eller fax software der fejler.