Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 19 reacties
Bron: Kernel.org

Gillse gezet. Sinds pre8 zijn dit de veranderingen:

Linux Kernel 2.4.8 final:

  • Rik van Riel: free up swap cache on swapin when swap is full..
  • Robert Love: merge emu10k sound driver. This one is better ("Yeah, you actually get sound out of it")
  • Jeremy Linton: swapin/swapoff race condition fix
[break]Complete log van Kernel 2.4.8 vind je hier[/break]

Lees meer over

Versienummer:2.4.8
Besturingssystemen:Linux
Website:Kernel.org
Download:http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.8.tar.gz
Moderatie-faq Wijzig weergave

Reacties (19)

't gaat er wel op vooruit, nu nog ff wachten op 2.5 en dan komen er weer distro's met de nieuwe kernel, kernel compilen kan ik niet dus moet ik ff wachten op de iso versies
er staan toch genoeg howto's op de verschillende sites voor het compileren van een kernel.

make clean
make xconfig
alles naar je hand zetten
make dep
make bzImage
make modules
make modules_install
image copieëren naar de boot directory
in etc/lilo.conf opgeven dat je een nieuwe kernel heb
reboot.

wauwie, wéér een mini howto erbij :)
humsss? waarom met 1 thread compilen?? op machines met 1 processor kan je het best met 4 threads tegelijk werken, op machines met 2 of meer procs kan je het beste 4 threads per proc nemen, 8 threads for dual proc machine dus.

maak in je Makefile een regel 'make=make -j4' (voor up machines) of '-j8' (voor smp machines)

kijk maar eens hoeveel tijd het scheelt ;-)

al je regels van make blabla, make blabla in een 'do' bestandje zetten, en uitvoeren met time ./do
do bestandje moet natuurlijk wel uitvoerbaar zijn.... chmod 755 do
en je vergat het naderhand updaten van lilo records, lilo -v
burne> Overigens ken ik niemand die op een OS anders dan linux probeert een linux-kernel te bakken..

Ohnee? nooit een Free/Net/OPEN BSD kernel gebakken? irix? Beos? zolang het een posix compliant os is, kan je nog steeds source code verkrijgen en kernel compilen (voor commercieele shit moet je eerst officieel developer zijn, ik ben nu devel voor FreeBSD en werk o.a. aan ATA driver, aangezien ik dat ook bij Linux gedaan heb (i386,alpha arch) is wel leuk.. heb je toegang tot de nieuwste (kernel- ) source en in de meest zware en soms brakke develop status :)

Zo.. me moet nog heel ff een paar seconden wachten.. en dan komt me nieuwe FreeBSD 4.4 kernel uit de oven

<verbaasd>
Huh??? waarom gemodereerd? wat is dit voor onzin?
</verbaasd>

Er wordt hier echt belachelijk beoordeeld. dit zorgt er dus voor dat mensen MET een beetje kennis hier nietmeer zullen posten. Aangezien de nitwis toch de meest vreemde reacties geven... zucht.. gewoon zonde.
Of meerdere threads uitmaken zal heel erg afhangen van waar 'm de bottleneck zit. Als je een kernel compiled op een P200MMX maakt -j<veel> niets uit. Je CPU is het probleem, en je CPU vier dingen tegelijk laten doen zal je build bepaald niet versnellen. Op een 2GHz Xeon is je schijf waarschijnlijk hetgeen wat voor problemen zal gaan zorgen, en met hoeveel threads je het snelst bouwt hang dan af van je schijf(array).

Overigens wordt er een thread weggesnoept door make, dus -j4 levert je drie actieve threads op. De vierde is alleen even wakker als een van de drie klaar is met iets, en vervangen moet worden door een nieuwe thread met een nieuwe compile.
Ik begrijp je kijk erop, maar het klopt niet helemaal. namelijk, de keuze van 4 threads voor een goede process bezetting (belasting van cpu) is bepalend voor welk os je draait en heeft nog even niets met je gebruikte hardware te maken. voor possix compliant os's als linux geldt gewoon dat 4 threads een mooie belasting vormt. (komt door threads scheduler, die tijd vrij wil houden voor nieuwe processen, zodat bijv. users die inloggen gelijk een stukje processor tijd toegewezen krijgen zodat ze niet hoeven te wachten -> prima voor server systeem) maar ok, wat je zei over gebruikte hardware.. het klopt ook niet 100% want stel dat je cpu nou lekker overpowered is, en je hd de ware bottleneck.. dan heeft het geen zin om meerdere threads te gebruiken, de hd is immers te traag om de gegevens aan te leveren/ weg te schrijven, dus bottleneck blijft bottleneck. wanneer hd dus te traag is kan hij ook geen bron informatie opleveren voor de (velen?) threads die je op dat systeem wil laten lopen.
Inderdaad komt er een punt dat meer threads je build gaan vertragen. Als je me niet gelooft moet je maar eens kijken wat er gebeurd na een make -j100. Het merendeel van je threads zal in een of ander vorm van wachttoestand staan, wachtend op completion van een of andere vorm van IO.

Welke mate van multithreading optimaal is hangt af van CPU, geheugen- en disksnelheid. Door een van de drie te verhogen worden de andere twee meer belemerend voor hogere prestaties.

Overigens ken ik niemand die op een OS anders dan linux probeert een linux-kernel te bakken.. :)

Ik heb in het verleden veel gespeeld met een 6 CPU Xeon. Daar was make -j13 optimaal voor compileren van een enkele lokale schijf, en -j37 als je kernel, output en tempspace op de netapp zette. Meer en minder leverden langere buildtijden op. Met snellere Xeons zal dat waarschijnlijk wel verder stijgen, net zoals met snellere I/O.
Maar wanneer je hdd vrijwel alleen gebruikt wordt voor het lezen van de source code (dus wanneer je dusdanig veel vrij geheugen hebt dat het niet meteen weg geschreven hoeft te worden naar disk) dan moet je een wel heeel erg trage schijf hebben (of een erg snelle CPU met erg rappe mem-toegang) wil die de bottleneck zijn bij het compileren.
Zeker op een multi CPU- machine wordt vaak de IO door één CPU afgehandeld en het compileren dan door beide.
Het voordeel is dan dat je toch een behoorlijke snelheids winst kunt krijgen met meerdere threads.
Het is wel zo dat op een gegeven moment meer threads niet veel voordeel geven, maar het moeten er wel behoorlijk veel zijn, wil je compileertijd weer langer gaan duren (door de overhead van process swappen en/of geheugen tekort)

En ff over de kernel....
Robert Love: merge emu10k sound driver. This one is better ("Yeah, you actually get sound out of it")
't zal eindelijk eens tijd worden, ik heb die kaart nu al ruim 2.5 jaar en nog steeds geklooi ermee onder Linux (SMP-bak)
er komt geen 2.5, de oneven nummers na de hoofdversie worden gebruikt voor test-versies.. net zoals er ook nooit een officiele 2.3.x was (behalve beta's enzo dan)

dus je bedoelt dat 't wachten is geblazen op 2.6.x :)
enne.. kernels compilen is zo moeilijk niet, hoor. en ik denk dat 2.6.x nog wel even een tijdje op zich laat wachten.. ik heb er nergens nog iets over gelezen, dus reken er maar niet op dat 'ie binnen een jaar komt..
Wanneer 2.5 kernels komen zullen er vrij snel distros komen met 2.4 kernels, ik denk dat dit hetgeen is wat markvt wil zeggen. :)
Bijna alle distro's gebruiken al 2.4 kernels :).
Operating Systems: Linux i386
dammit :( wordt toch tijd dat linux ook eens naar andere platforms geport gaat worden, schiet niet op zow... ik ook lekker linux op me PPC willen kunnen draaien! |:( |:( |:(
Zeg meneer reflex. Je zet je zelf te kijk door met 3 |:( 's te janken. Als je je een beetje had ingespannen had je geweten dat er behoorlijk wat PPC distro's zijn !

Suse heeft bv. een PPC versie en zo zijn er genoeg. Succes met zoeken en installeren.

En over dat "i386". Je kan de kernel source downloaden en zelf een PPC kernel bakken.
* 786562 saintnightmare
Kijk hier:

http://www.linux-mandrake.com/en/ftp.php3

voor Mandrake voor PPC, er zijn echt genoeg distro's die een PPC versie hebben.
Laat maar reflex, er wordt waardeloos beoordeeld hier. Sinds ik dat getikt had in m'n post, ging m'n beoordeling even omhoog, maar daarna kwam er weer zo'n kneus die alle beoordelingen negatief maakte.. zucht.. wat moet je ermee?
ik weet dat er linuxdistros zijn voor veel verschillende architecturen, t ging er puur om dat t er fout stond 'Linux i386' en dat is jammer :'(

edit:

en ik snap niet waarom ik een troll krijg omdat ik iets wat fout is probeer recht te zetten.
ok, ff iets rechtzetten dan.
t was sarcasme voor degene die t woord kennen. omdat er ($%*_@ altijd i386 staat, en dat vrij vermoeiend wordt... ;(

t was meer bedoeld als 'grappig' aangeven dat t dus NOGSTEEDS (want ik zei t een half jaar geleden ook al) fout is... maar sommige mensen geen gevoel voor humor hebben
Debian heeft ports van de distro naar i386 m68k alpha sparc powerpc arm !

Linux draait al jaren op niet intel spul
Dat kan al lang hoor.

Op dit item kan niet meer gereageerd worden.



© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True