linux kernel suxx

[Sjonny]

jaa.. je leest het goed
na al die juigende mensen hier in [topic=212817] te hebben gezien wou ik nou toch wel ff wat gal spuwen

ik draai nou zo'n 4 jaar met linux, en heb echt af en toe een gloedharde hekel aan die windows meuk omdat het voor geen flikker werkt wat ik wil, en onder linux stukken minder last van, maar nou begint die linux kernel toch wel ff beetje puin te worden. en nou begint Win2k me ook nog te bevallen, wat eigenlijk helemaal de bedoeling niet is...

Voor iedereen die al 2.4.8 en 2.4.9 hebben geprobeerd moeten toch wel een beetje weten waar ik het over heb. Zit je daar een Divx te kijken (met zo'n kut lijntje onderin door die klote support voor een TNT2 kaart van Nvidia) en beroerd geluid omdat de alsa drivers voor de via8233 southbridge sound ding niet goed hun best doen en het geluid vervormen (lijkt op klipping ala schor-klank probleem).
Ondertussen zit dus die Divx in me brand-new 256Mb DDR ram, en is me XWindows en gnome en de helemeuk naar me swap gemoved WTF is dat?? Ik snap ook wel dat die Mem management van linux een beetje wordt omgegooit, maar is hier niet de development tree voor?? Waar het trouwens weer es hoog tijd voor wordt, dan kan iedereen weer naar hartelust in de kernel rond vroeten, heb ik binnenkort weer een kickass kernel

[Verwijderd]

die development tree is 2.3 geweest. Niemand had klachten op de memory management of in elk geval geen conrete verbeteringen....

Iki kan je nu wel miljarden threads uit linux-kernel gaan voorlezen maar dat heet tegenwoordig spam dus dat doe ik maar niet. Waar het op neerkomt is dat het nou eennmaal zo is. Heb je 2.4.5 gehad? Dán weet je pas wat kut is. Ik blijf sinds 2.4.5 lekker op 2.2.19, de stabiele kernel, die werkt en dat weet je. 2.4.x is development. Het heet stable maar dat is het niet. Punt.

Ik zal je binnenkort wel een mailtje geven van een woedeuitbarsting op onze deve-mailinglist van een idioot die de godganse wereld bij elkaar schreeuwde omdat zijn dc10+ het niet deed en linux was zo kut en dit was zo klote en dat....

De enige zinnige reactie kwam van projectleider Andrew:

Calm down

Take a beer.

Relax

Calm down again

Take another beer

You're using the newest and most brand new development kernel stuff, dc10+ mjpeg drivers and development versions of the mjpegtools. This is not meant for everyday use. The end. That's it. If you want to test, go ahead, we'll be pleased. If you don't, go back to 2.2.19, go back to our old and functional though limited 1.4-stable and don't bother us.

Kijk eens goed naar wat hij zegt. Je gebruikt de gloednieuwste development, nauwelijks in productie geteste kernels. Je gebruikt het nieuwste wat er is. Vind je het gek dat dat niet perfect is???

Hou het hierop. Deze discussie is zinloos. Linux is goed omdat er veel getest is maar de weinig-geteste versies zijn weinig-getest en kunnen dus slecht zijn.

The end.

[alt-92]

Vergeet je niet op tijd adem te halen?

[Pc123]

Ik vind de 2.4.x kernel echt super, een stuk sneller en nog nooit problemen gehad. Maar dat is mijn ervaring, het kan best dat er mensen zijn die problemen hebben.

[Sjonny]

Op zaterdag 25 augustus 2001 22:33 schreef beelzebubu het volgende:
die development tree is 2.3 geweest. Niemand had klachten op de memory management of in elk geval geen conrete verbeteringen....

Met 2.3.99pre9 had ik ook geen enkele moeite .. perfecte kernel was dat, devel kernel btw..

Iki kan je nu wel miljarden threads uit linux-kernel gaan voorlezen maar dat heet tegenwoordig spam dus dat doe ik maar niet. Waar het op neerkomt is dat het nou eennmaal zo is. Heb je 2.4.5 gehad? Dán weet je pas wat kut is. Ik blijf sinds 2.4.5 lekker op 2.2.19, de stabiele kernel, die werkt en dat weet je. 2.4.x is development. Het heet stable maar dat is het niet. Punt.

2.4 is even, en zou dus per definitie stable moeten zijn, daarom zeg ik ook, hier met die 2.5, want die 2.4 gaat tegenwoordig nergens over..

Hou het hierop. Deze discussie is zinloos. Linux is goed omdat er veel getest is maar de weinig-geteste versies zijn weinig-getest en kunnen dus slecht zijn.

The end.

hmmz, zoals ik dus al zei, 2.4 zou een stable tree moeten zijn ipv devel. als devel kernel me deze dingen flinkt heb ik er ook geen moeite mee, en als 2.2.19 laatste stable is, zijn ze voor nix met 2.3 genokt en naar de 2.4 gesprongen.

ik draai dus met die 2.4.9 omdat sinds daar die via drivers voor me K7T266 mobo zijn gemikt, en me ibm hdd met 30Mb+/s razend snel is, ipv pruttelen met 5Mb/s... scheelt toch ook wel wat.

[Verwijderd]

Op zaterdag 25 augustus 2001 22:36 schreef BackSlash32 het volgende:
Vergeet je niet op tijd adem te halen?

Het ging even om het idee... Er is zoveel afgeflamed op linux-kernel, op bijna elke mailinglist zelfs, over 2.4.x. Ik ben er gewoon ziek van... Wil gewoon dat mensen een beetje begrijpen waarom dat zo is... Flamen is veel te makkelijk... (overigens is deze post absoluut geen flame, maar het idee achter mijn reactie zal je wel begrijpen)

/me haalt adem

[igmar]

Iki kan je nu wel miljarden threads uit linux-kernel gaan voorlezen maar dat heet tegenwoordig spam dus dat doe ik maar niet. Waar het op neerkomt is dat het nou eennmaal zo is. Heb je 2.4.5 gehad? Dán weet je pas wat kut is. Ik blijf sinds 2.4.5 lekker op 2.2.19, de stabiele kernel, die werkt en dat weet je. 2.4.x is development. Het heet stable maar dat is het niet. Punt.

Wat minder kankeren, de threads wat beter lezen, en dan ook weten wat er mis is. Het probleem is het zoned memory.

De ac reeks lost de meeste problemen op is mijn ervaring. De veranderingen aan 2.4.x tov 2.3 wat betreft memory management zijn discutabel, maar de laatste ac reeks is in ieder geval een grote verbetering.

Dat er een probleem is met het VM systeem wil niet zeggen dat het een 'development' kernel is.

[Sjonny]

oi, strak plan van die ac patch ... ook ff halen, je weet maar nooit

[Verwijderd]

Op zaterdag 25 augustus 2001 22:40 schreef Sjonny het volgende:
2.4 is even, en zou dus per definitie stable moeten zijn, daarom zeg ik ook, hier met die 2.5, want die 2.4 gaat tegenwoordig nergens over..

Maar dat is het dus niet. Het is bleading-edge. Gloednieuw. Vaak slecht- of niet-getest. Dan is het nou eenmaal niet superstabiel. Accept that. 2.2.x is stable. 2.4.x is current. Niet stable. Het idee van even=stable/odd=unstable is veel te simpel gedacht. Je kan niet met een vingerknip een driver stable maken....

ik draai dus met die 2.4.9 omdat sinds daar die via drivers voor me K7T266 mobo zijn gemikt, en me ibm hdd met 30Mb+/s razend snel is, ipv pruttelen met 5Mb/s... scheelt toch ook wel wat.

Lees nou eens goed wat je zegt. Jij wilt bleading-edge gloednieuwe functionaliteit maar wel stabiel. Weet je wel wat je hier zegt???

Herlees het. Dit kan niet. Nieuw kan niet stabiel zijn. Stabiel betekent jarenlang in productie getest. Dus als 2.6.1 uit is, dan pas is 2.4.x stabiel. Tot dan is het current, niks meer niks minder. Als je stable wilt kun je geen bleading-edge verwachten.

Accept it.

[Verwijderd]

Op zaterdag 25 augustus 2001 22:41 schreef igmar het volgende:

[..]

Wat minder kankeren, de threads wat beter lezen, en dan ook weten wat er mis is. Het probleem is het zoned memory.

Ik weet heus wel waar al die problemen liggen - volg het niet voor niets op de voet

[Sjonny]

ik vindt het eigenlijk ook niet echt vreemd dat er op dit punt veel wordt geflamed, eigen schuld, dikke bult.
maar als er pas in weet ik het wanneer met die 2.5 tree wordt begonnen, en die 2.4 is niet compleet stable en de echt laatste stable is 2.2.19, dan gaat er toch iets mis met de organisatie daar...

[RG]

Waarom krijgt de kernel nou altijd de schuld van brakke drivers? Dat NVidia geen drivers kan proggen is duidelijk. Ik draai sinds kort gewoon op de standaard XFree86 drivers en dat gaat veel en veel beter.
Persoonlijk heb ik nog nooit problemen gehad met de kernel en ik heb echt niet zo'n standaard hardware. Persoonlijk heb ik veel vaker ruzie met XFree86 die mijn muis en toetsenbord laat hangen en daar wordt ik nog wel eens boos over...

Ik draai ook bijna nooit de nieuwste kernel. Nu 2.4.7 en die bevalt me echt goed dus die blijft er voorlopig lekker op staan. 2.2 kernels vind ik te prehistorisch. Vooral als je een TV kaart enzo hebt is een 2.4 kernel toch wel errug handig (naja dat ligt aan de nieuwe BTTV drivers magoed).

[RG]

Op zaterdag 25 augustus 2001 22:49 schreef Sjonny het volgende:
ik vindt het eigenlijk ook niet echt vreemd dat er op dit punt veel wordt geflamed, eigen schuld, dikke bult.
maar als er pas in weet ik het wanneer met die 2.5 tree wordt begonnen, en die 2.4 is niet compleet stable en de echt laatste stable is 2.2.19, dan gaat er toch iets mis met de organisatie daar...

2.5 tree bestaat nog helemaal niet, wat lul je nu???

[alt-92]

Op zaterdag 25 augustus 2001 22:41 schreef beelzebubu het volgende:
(overigens is deze post absoluut geen flame, maar het idee achter mijn reactie zal je wel begrijpen)

/me haalt adem

O, maak je daar geen zorgen om Dat adem halen was meer voor Johnny bedoeld trouwens (warm is het hè, da's goed voor de bloedsomloop)

Wat betreft het al dan niet stable/current debat: een goed voorbeeld van een niet-geteste functionaliteit is NTFS read support in 2.4.8(werkt wel) en 2.4.9(stuk).

Nieuwer != beter dus.

[Sjonny]

Op zaterdag 25 augustus 2001 22:45 schreef beelzebubu het volgende:
Lees nou eens goed wat je zegt. Jij wilt bleading-edge gloednieuwe functionaliteit maar wel stabiel. Weet je wel wat je hier zegt???

Herlees het. Dit kan niet. Nieuw kan niet stabiel zijn. Stabiel betekent jarenlang in productie getest. Dus als 2.6.1 uit is, dan pas is 2.4.x stabiel. Tot dan is het current, niks meer niks minder. Als je stable wilt kun je geen bleading-edge verwachten.

Accept it.

ik had dan ook niet verwacht dat die via driver stabiel zou zijn, maar me memory management toch wel wat meer. 2.4.3 had er lang niet zo veel last van. snap ook wel dat 2.4.9 niet getest is, dat doe ik dan zelf wel en post hier ff mijn bevindingen omdat ik er een beetje de schijt van had.
laat ze dan 2.4.x stabilizeren, en in 2.5 mogen ze van mij gaan klooien wat ze willen, die ga ik dan ook wel weer mee spelen.. ik dacht ook eigenlijk meer dat dat de bedoeling zou worden na die linux conferentie van een paar maanden geleden...

[RG]

Op zaterdag 25 augustus 2001 22:45 schreef beelzebubu het volgende:
Herlees het. Dit kan niet. Nieuw kan niet stabiel zijn. Stabiel betekent jarenlang in productie getest. Dus als 2.6.1 uit is, dan pas is 2.4.x stabiel. Tot dan is het current, niks meer niks minder. Als je stable wilt kun je geen bleading-edge verwachten.

Accept it.

Klopt... Pas als Linus kernel 2.4.x stabiel vindt, wordt pas de kernel 2.5 development tree geopend en wordt de maintainer van kernel 2.4 Alan Cox. En aangezien de 2.5 tree er nog niet is, heeft Linus 2.4 nog niet als stabiel zijnde verklaard...

[Sjonny]

Op zaterdag 25 augustus 2001 22:53 schreef BackSlash32 het volgende:
O, maak je daar geen zorgen om Dat adem halen was meer voor Johnny bedoeld trouwens (warm is het hè, da's goed voor de bloedsomloop)

Wat betreft het al dan niet stable/current debat: een goed voorbeeld van een niet-geteste functionaliteit is NTFS read support in 2.4.8(werkt wel) en 2.4.9(stuk).

Nieuwer != beter dus.

dat ademhalen gaat een beetje vanzelf .. heel gek is dat
en die ntfs was alleen een missing #include "kernel.h", dat kan ik ook nog wel fixen

[Verwijderd]

Op zaterdag 25 augustus 2001 22:54 schreef Sjonny het volgende:
[..] laat ze dan 2.4.x stabilizeren, en in 2.5 mogen ze van mij gaan klooien wat ze willen [...]

grapje?

[Sjonny]

Op zaterdag 25 augustus 2001 22:55 schreef Groot-Moefti het volgende:
Klopt... Pas als Linus kernel 2.4.x stabiel vindt, wordt pas de kernel 2.5 development tree geopend en wordt de maintainer van kernel 2.4 Alan Cox. En aangezien de 2.5 tree er nog niet is, heeft Linus 2.4 nog niet als stabiel zijnde verklaard...

Ahh .. die is fijn
dus zoals het er nu voor staat duurt het nog wel ff voordat die 2.5 er is ... damn.

[alt-92]

Op zaterdag 25 augustus 2001 22:56 schreef Sjonny het volgende:
dat ademhalen gaat een beetje vanzelf .. heel gek is dat

en die ntfs was alleen een missing #include "kernel.h", dat kan ik ook nog wel fixen

Kun je een kernelbakkende n00b dat kort uitleggen hoe je dat doet?
Ben wel bezig geweest met een patch van linux-kernewl, maar ik kwam er niet helemaal uit.

[Sjonny]

Op zaterdag 25 augustus 2001 22:58 schreef beelzebubu het volgende:



grapje?

ut wordt toch niet te persoonlijk voor je?
ik snap ook wel dat er hard aan gewerkt wordt, en als ik wat meer tijd overhad, en wat meer gelezen had over hoe je die mem problemen goed kan aanpakken had ik ook nog wel mee gedaan met de kernel devepment. beetje flauw natuurlijk om aan de kant van alles te roepen, wat ik nu fijn sta te doen

[Sjonny]

Op zaterdag 25 augustus 2001 23:01 schreef BackSlash32 het volgende:

Kun je een kernelbakkende n00b dat kort uitleggen hoe je dat doet?
Ben wel bezig geweest met een patch van linux-kernewl, maar ik kwam er niet helemaal uit.

in die uni-dinges.c file was er een error over die min(,) functie. maar min heeft meestal maar 1 param, en geen 2, dus is speciale functie... ga je in die ntfs dir met grep zoeken naar die min, wordt veel gebruikt, maar definitie zit niet in deze dir. dus moet je de includes af. kijk je waar min(,) gebruikt wordt en zoek je die include op, prik je in je uni-dinges.c, make in de top dir, en tada ..

[Verwijderd]

Op zaterdag 25 augustus 2001 23:02 schreef Sjonny het volgende:

[..]

ut wordt toch niet te persoonlijk voor je?
ik snap ook wel dat er hard aan gewerkt wordt, en als ik wat meer tijd overhad, en wat meer gelezen had over hoe je die mem problemen goed kan aanpakken had ik ook nog wel mee gedaan met de kernel devepment. beetje flauw natuurlijk om aan de kant van alles te roepen, wat ik nu fijn sta te doen

Niet persoonlijk (ik ben slechts driver-helper), maar oh zo makkelijk gedacht.

"laat ze 2.4 stabiel maken en met 2.5.x gaan spelen".

Bedenk alsjeblieft dat die hele kernel voor linux "all for fun" is. Misschien wel 1-miljard-dollar fun, maar het blijft fun. Voor Linus is 2.4.x een speeltuin. Die hele kernel is voor hem een speeltuin. Een serieuze speeltuin, maar wel een speeltuin.

[Sjonny]

Op zaterdag 25 augustus 2001 23:06 schreef beelzebubu het volgende:
"laat ze 2.4 stabiel maken en met 2.5.x gaan spelen".

Bedenk alsjeblieft dat die hele kernel voor linux "all for fun" is. Misschien wel 1-miljard-dollar fun, maar het blijft fun. Voor Linus is 2.4.x een speeltuin. Die hele kernel is voor hem een speeltuin. Een serieuze speeltuin, maar wel een speeltuin.

en ik heb ook flink wat lol beleeft al met linux,
en ik zou echt geen problemen hebben als linus ze speeltuin in 2.5 verder zet mag alan die zooi in 2.4 opruimen

[Servowire]

tja.
dan installeer je Win2k, werkt goed hoor

[RG]

Ach kernel 2.4 is best wel goed... Het enigeserieuze probleem dat bekend is, is dta van het geheugenmanagment... ALs je geheugen vol zit, zou Linux kunnen crashen.
Verder zijn het allemaal driverproblemen, dus dat heeft geen ruk met de kernel op zich te maken.
Ik had bijvoorbeeld helemaal geen probleem met DivX'en kijken met kernel 2.4

[RG]

Op zaterdag 25 augustus 2001 23:36 schreef Servowire het volgende:
tja.
dan installeer je Win2k, werkt goed hoor

Ja wel als je 500 gulden hebt... En dan nog is kernel 2.4 stabieler dan Windows2000

[Sjonny]

Op zaterdag 25 augustus 2001 23:36 schreef Servowire het volgende:
tja.
dan installeer je Win2k, werkt goed hoor

staat er ook op. alleen dan op me 8Gig hdd, en Win2k kan niet echt me ext2 en reiserfs disks lezen helaas. en in linux zit geen write support voor win2k ntfs disks, dus dat schiet niet zo op eigenlijk. en een partitie in fat32 voor data sharing is ook maar zozo, maar wel een oplossing though ..
was wel blij te lezen dat die ntfs meuk tegenwoordig gesponsord is .. misschien geeft dat een beetje een speedup in de developent

[Sjonny]

Op zaterdag 25 augustus 2001 23:40 schreef Groot-Moefti het volgende:
Ik had bijvoorbeeld helemaal geen probleem met DivX'en kijken met kernel 2.4

gemier begon ook pas bij .8, daarvoor (laatste try .3) geen probs. en het is ook niet alleen met divx, maar ook als je bv nautilus, staroffice, mozilla en dat soort zooi er tegelijkertijd in heb zit je ook binnen no-time in je swap, wat ik van me 256mb toch eigenlijk niet verwachte.
copy ander wel die via-driver van 2.4.9 naar 2.4.3 en kijken of het nog werkt

[Refragmental]

1 ding snap ik niet echt,
jullie zeggen dat 2.4.x Current is en dus niet superstable.
Maar wanneer 2.6.x uitkomt is 2.4.x plots wel superstable,
maar 2.4.9 blijft 2.4.9 en blijft dus zo stabiel zoals ie nu is.
Ook al komt 2.8.x uit, 2.4.9 blijft zo stabiel als nu.

Ik had trouwens ook een vraag, wat gebeurd er in de 2.(even).x reeks???
Worden dan alleen maar dingen gedebugged, en worden er geen extra features meer bijgezet?
Dus stoppen ze dan met 2.4.x totdat ie echt helemaal gedebugged is?
Als dat zo is kun je me eerste paragraaf negeren

Maar als ik het goed begrijp, is 2.2 de laatste goed gedebugde kernel en dus goed stabiel, en 2.4 wordt nu gedebugged.

[picobyte]

Hmm... ontevreden ?
Hoe dat zo ??
Ik doet hier DIVX;-) en ook MP3 en natuurlijk games
Mijn TNT2 en GF1-256 hebben hier geen problemen, alleen wil die emu10k1 module nog weleens de 8er speakers "vergeten" waarneer ik een CPU-intensive task start
Maar dat is gewoon het proggie en heeft totaal niets met de kernel te maken!
Er is gewoon veel ßrakke/ongeteste/ software in omloop in de linux wereld, het is dan ook niet voor niets een "diehard OS"
Hebbie ooit wel eens een pinguin zien bevriezen
Je moet weten wat je doet met je machine en ook de debug berichten kunnen lezen!
Zelf gebruik ik voornamelijk kernel 2.2.14 met de NVIDIA downloaded driver en ik heb ook inmiddels een 2.4.x draaien met UT... ik vindt het dan ook wel stabiel met bijkomend voordeel dat mijn user "ut" alleen maar mijn UT-server kan en mag serveren

[Roel]

Op zondag 26 augustus 2001 00:04 schreef Legion een heel verhaal

Natuurlijk wordt 2.4.9 nog verder gedebugged en dan komt er een nieuwe uit (2.4.10).
2.2.19 is nou de stabielste uit de 2.2.x tree, worden er in 2.2.19 bugs gevonden die de moeite waard zijn krijg je 2.2.20.

Komt 2.6 uit dan weet je dat 2.4 helemaal stable is volgens Linus en ze met de volgende kunnen beginnen. 2.2.x is dan helemaal oud en dan kun je beter upgraden.

Draai hier zelf met 2.4.5 en 2.4.6 zonder problemen.
(en btw, als er bugs in zitten dan ga je toch lekker zelf aan de slag met debuggen ? )

[RG]

In de 2.4 reeks komen er bij elke versie nieuwe drivers bij en zijn er bugfixen. Ingrijpende veranderingen komen pas bij een nieuwe tree. Dus bijvoorbeeld SMP support, geheugenbeheer, etc...

[Verwijderd]

Op zondag 26 augustus 2001 00:04 schreef Legion het volgende:
1 ding snap ik niet echt,
jullie zeggen dat 2.4.x Current is en dus niet superstable.
Maar wanneer 2.6.x uitkomt is 2.4.x plots wel superstable,
maar 2.4.9 blijft 2.4.9 en blijft dus zo stabiel zoals ie nu is.
Ook al komt 2.8.x uit, 2.4.9 blijft zo stabiel als nu.

Het is een naam. Stable, development, current. Als je in BSD hebt meegelopen weet je wel wat die namen betekenen. Het is niet de staat van het product, het is de development branche name van de tree.

Stable betekent goed-getest, weinig bugs (over het algemeen), ... Er mag geen nieuwe feature worden geimplmenteerd in stable. Stable is voor bug-fixing only. Current is huidige test-versie voor stable. Is in ontwikkeling maar drivers moeten goed getest zijn voordat ze erbij mogen. Development is "leef je raak".

2.2.x is stable. Kan bugs hebben maar mag geen nieuwe features krijgen. Krijgt dus waarschijnlijk geen nieuwe bugs. 2.4.x is current. Kan dus in hopeloze gevallen per ongeluk nieuwe bugs krijgen. 2.3.x was en 2.5.x wordt development - leef je raak en gebruik het niet in production want you'll be sorry.

Zoals hierboven al gezegd door iemand anders zal 2.4.10 bugfixes t.o.v 2.4.9 hebben en als 2.6.x er eenmaal is dan wordt 2.4.x de maintainance branche en is 2.6.x voor de nieuwe foefjes.

[Verwijderd]

Maar ik ben geen schaap, en gebruik linux.

ik draai op dit moment 2.4.9, maar ik heb ook vanaf 2.4.1 gedraait. Maar met 2.4.9 heb ik helemaal geen problemen.

Spellen draaien bij mij beter onder linux dan onder M$ windows. En dat was 1 van de redenen dat ik vroeger (2a3 maand geleden) nog M$ rommel op mijn computer had staan.

Maar wil je je kernel een beetje voor elkaar hebben, moet je veel lezen.

(Een mens is een kudde dier, en daar heeft M$ gebruik van gemaakt.)

[igmar]

Lees nou eens goed wat je zegt. Jij wilt bleading-edge gloednieuwe functionaliteit maar wel stabiel. Weet je wel wat je hier zegt???

Herlees het. Dit kan niet. Nieuw kan niet stabiel zijn. Stabiel betekent jarenlang in productie getest. Dus als 2.6.1 uit is, dan pas is 2.4.x stabiel. Tot dan is het current, niks meer niks minder. Als je stable wilt kun je geen bleading-edge verwachten.

De meeste functionaliteit zijn zaken die zichzelf al bewezen hebben, vaak als losstaande patch. Hieronder LFS, ReiserFS en meer van dat soort zaken.

Het enige echt nieuwe is het zoned memory, en dat is ook precies waarom de problem nu te vinden zijn. Voor emterprise systemen (8 CPU's, 100 GB intern geheugen ed) is zoned memory een vereiste.. Helaas word er veel mee gekloot, omdat er twee partijen lopen te touwtrekken.

[Verwijderd]

Op zondag 26 augustus 2001 13:43 schreef igmar het volgende:
De meeste functionaliteit zijn zaken die zichzelf al bewezen hebben, vaak als losstaande patch. Hieronder LFS, ReiserFS en meer van dat soort zaken.

LFS als in....? Linux From Scratch? Ik mag toch hopen dat je weet wat je hier zegt he?

Ik vind deze opmerking uberhaupt al niet erg zinnig... Functionaliteit wordt bepaald door hoe zinnig de feature is voor de gebruikers.

Het enige echt nieuwe is het zoned memory, en dat is ook precies waarom de problem nu te vinden zijn. Voor emterprise systemen (8 CPU's, 100 GB intern geheugen ed) is zoned memory een vereiste.. Helaas word er veel mee gekloot, omdat er twee partijen lopen te touwtrekken.

Ik vraag me wederom af of je weet wat je zegt hier....

Het hele VM gedoe in de kernel is mijns inziens brak omdat:
1) swapoff() een functie is die gewoonweg brak is en sowieso niet mag bestaan. Je halve geheugen wordt opeens in swap gezet. Ik vind dat een backgroundtask constant je mem/swap in de gaten moet houden en veelgebruikte data in de mem houden en minder gebruikte data *alleen indien nodig* in de swap zet. Het hele idee van je volledige mem in swap zetten is zo brak als maar kan!
2) die VM is slecht getest.
3) mensen die er totaal geen verstand van hebben maken er opmerkingen over die nergens op slaan. Patches die er niet horen worden zonder enige reden zelfs aangenomen met 2.4.5 als absoluut dieptepunt. Need I say more? Ze hebben meer tijd nodig. 2.4.x VM is gewoonweg niet productieklaar. Niks zoned memory probleem - het is een veel uitgebreider probleem. Volg linux-kernel als je dit interessanmt vind

[Mior]

Ik ben niet zo op de hoogte van de kernel development allemaal.

Maar is dit niet JUIST de reden dat er aan 2.2.x nog steeds door ontwikkeld wordt

En als 2.4.x nog development is, waarom wordt dat dan niet officieel vermeld? Of zijn alleen bepaalde functies nog in de develop status?

[Jordi]

Hier en daar zie ik nog een klein beetje geflame, kom op jongens, dit is de Huiskamer niet

Ik vind 2.4 ook nog niet echt geweldig... paar keer geprobeerd op workstation, maar... ik begin er een beetje een vies smaakje van te krijgen eigenlijk. Waar is die spirit 'linux = stabiel' ? Die wazige compile errors en een joystick op een es1370 soundkaart die met geen mogelijkheid aan de praat te krijgen is... ik vind het maar niks. Zou dit weer tijd worden om te switchen van OS? Ik hoop het niet, maar als het zo doorgaat...

[RG]

Er is niks mis met kernel 2.4. In 9999 van de 10000 situaties zal ie perfect voldoen. Het enige dat vaak niet goed is, zijnd e drivers, maar die hebben geen ruk te maken met de kernel op zich. Het enige probleem met kernel 2.4 is dus dat met het geheugen, maar daar heb je ook vrijwel nooit last van. Gebruik gewoon de kernel die je zelf het beste vind. Ik 2.4.7. Heb er nog geen problemen mee gehad, heeft ReiserFS, goede TV kaart support, etc... Die blijft er dus gewoon op. En vergeet niet dat veel van de features van 2.4 gewoon overgezet zijn naar de 2.2 reeks, al dan niet officieel (SuSE met hun USB support enzo)...

IMHO moet je gewoon gebruiken wat je zelf het beste vind. Voor mij is dta 2.4.7 voor iemand anders misschien 2.2.19 ofzo....

[odysseus]

Op zondag 26 augustus 2001 14:19 schreef beelzebubu het volgende:

[..]

Het hele VM gedoe in de kernel is mijns inziens brak omdat:
1) swapoff() een functie is die gewoonweg brak is en sowieso niet mag bestaan. Je halve geheugen wordt opeens in swap gezet. Ik vind dat een backgroundtask constant je mem/swap in de gaten moet houden en veelgebruikte data in de mem houden en minder gebruikte data *alleen indien nodig* in de swap zet. Het hele idee van je volledige mem in swap zetten is zo brak als maar kan!

Dit is het zeker niet. Een quote van Rik van Riel waarom je nog steeds veel swap nodig hebt als je meer RAM in je systeem zet:

The reason is that the Linux 2.4 kernel no longer reclaims swap space on swapin (2.2 reclaimed swap space on write access, which lead to fragmented swap space in lots of workloads).

This means that a lot of memory ends up "duplicated" in RAM and in swap. <<<-------

In een oudere thread schreef ik in discussie met deadinspace al eens:

Stel dat je 128MB RAM hebt en 64MB swap. Zoals Rik van Riel hierboven al beschreef wordt een groot deel van je RAM in je swap gemirrord. Je swap staat dan dus vol zonder dat ie ook maar *iets* nuttigs heeft kunnen doen...niet echt nuttig. Dat jij geen gebruik van je swapfile ziet en em dus niet nuttig vind is logisch: RAM/swap duplication vindt pas plaats zodra er echt een noodzaak is om naar je swap te gaan schrijven. Op dat moment komt het er in te staan en het gaat er niet meer uit zolang het ook nog in je RAM staat, en zelfs daarna niet van harte. In feite werkt het als volgt, bij mijn weten (kan het mis hebben):
RAM vol? -> zet iets in swap en verwijder dat uit het geheugen zodat daar weer ruimte is voor een actief programma
RAM heeft weer ruimte? -> zet terug wat nodig is, maar laat dat staan in de swap
RAM weer vol? -> je kunt het direct uit het geheugen gooien omdat je het in je swap hebt laten staan. Dit scheelt een hoop traffic en is dus sneller. Wat je hierdoor wel merkt is dat veel van wat in je RAM staat ook in je cache staat. Dit merk je dus alleen als je RAM goed gevuld is geweest.

Volgende argument:

2) die VM is slecht getest.

Tja, volgens mij willen ze daar juist wat aan doen...hoe kun je anders je VM testen dan door hem te (laten) gebruiken? Er was gewoon geen alternatief, met het testen door de grote groep gebruikers na de release van 2.4.0 zouden vanzelf de mogelijke problemen worden gevonden. De kleine groep mensen die ook development-kernels draait is niet groot genoeg om alle mogelijke situaties te ontdekken waarin de nieuwe VM niet voldoet. Overigens kon men ook niet de VM van 2.2 weer gebruiken, vooral omdat die bij mijn weten nogal gebrekkig werkt in de grotere (enterprise-)systemen, in vergelijking met de nieuwe VM althans.

3) mensen die er totaal geen verstand van hebben maken er opmerkingen over die nergens op slaan. Patches die er niet horen worden zonder enige reden zelfs aangenomen met 2.4.5 als absoluut dieptepunt. Need I say more? Ze hebben meer tijd nodig. 2.4.x VM is gewoonweg niet productieklaar. Niks zoned memory probleem - het is een veel uitgebreider probleem. Volg linux-kernel als je dit interessanmt vind

Doe ik... Heb hier ook al eerder discussies over gehad op GoT. Dat patches die er niet horen zomaar worden aangenomen lijkt me stug. Iedere developer die iets van het onderwerp weet kan dan zien dat de patch geen verbetering is en een andere schrijven of vertellen waarom de patch er niet in moet.
Het grote probleem met een VM is dat er zo ontzettend veel situaties zijn waarin hij zijn werk moet doen. Het kan nooit in alle situaties perfect gebeuren, dus moet je afwegingen maken. Na een release naar het grote publiek (bij de 2.4-release) blijken er dan altijd nog speciale omstandigheden te zijn waarin de VM niet goed werkt. Het probleem is dat je door dit te fixen vaak weer zes andere problemen sub-optimaal oplost.

* odysseus vindt de 2.4-VM niet altijd best, maar kan nu eenmaal geen andere situatie vinden om hem te verbeteren dan gewoon aan het publiek geven dat dan vanzelf wel commentaar geeft. VM is geen driver die het wel of niet doet, het is een veel complexer geheel.

[edit: Overigens heb ik nog nooit een crash gehad met een 2.4-kernel voor zover ik me kan herinneren, zelfs niet met de testkernels]

[jep]

Op zaterdag 25 augustus 2001 22:33 schreef beelzebubu het volgende:
Iki kan je nu wel miljarden threads uit linux-kernel gaan voorlezen maar dat heet tegenwoordig spam dus dat doe ik maar niet. Waar het op neerkomt is dat het nou eennmaal zo is. Heb je 2.4.5 gehad? Dán weet je pas wat kut is. Ik blijf sinds 2.4.5 lekker op 2.2.19, de stabiele kernel, die werkt en dat weet je. 2.4.x is development. Het heet stable maar dat is het niet. Punt.
[..]

Ik draai 8 servers op 2.4.5, allemaal 68 dagen uptime en erg prima. Dat heeft alleen niets te maken met divx'jes oid

[Sjonny]

odysseus:
kijk! da's nog es een duidelijk verhaal!
zal zelf toch ook maar es wat meer gaan lezen over die vm, toch wel leuk om je er mee bezig te houden.

[Verwijderd]

Op zondag 26 augustus 2001 16:38 schreef Jotti het volgende:
Ik vind 2.4 ook nog niet echt geweldig... paar keer geprobeerd op workstation, maar... ik begin er een beetje een vies smaakje van te krijgen eigenlijk. Waar is die spirit 'linux = stabiel' ? Die wazige compile errors en een joystick op een es1370 soundkaart die met geen mogelijkheid aan de praat te krijgen is... ik vind het maar niks. Zou dit weer tijd worden om te switchen van OS? Ik hoop het niet, maar als het zo doorgaat...

die joystick heb ik ook problemen mee gehad, een mailtje naar die jongen die de leider van het joystick project is (werkt bij Suse) en het werkte weer. es1370+joystick werkt inderdaad niet, ik kan mijn aagepaste es1370.c wel even posten als je wilt (van kernel 2.4.4) dan kun je zelf uitvinden wat er anders moet en dan doet ie het weer. Bij elke kernel heeft de joystick bij mij tot nu toe gewerkt, sdoms met wat handmatig gepriegel in die code...

Verder, nogmaals, alsjeblieft, 2.4.x is niet stabiel. 2.4.x is current - helaas.... Maar er valt momenteel niks aan te doen vrees ik.... Ik zou het namelijk niet beter kunnen

[Verwijderd]

Op zondag 26 augustus 2001 22:08 schreef j3p het volgende:

[..]

Ik draai 8 servers op 2.4.5, allemaal 68 dagen uptime en erg prima. Dat heeft alleen niets te maken met divx'jes oid

start een paar geheugen-intensieve taken en ze zullen lijken te crashen (als je het geduld hebt om te wachten totdat mem-naar-swap klaar is, kan enkele uren duren, zul je overigens zien dat ze het nog steeds doen ).

Toen had ik het wel gehad met 2.4.x

[Verwijderd]

Op zondag 26 augustus 2001 21:03 schreef odysseus het volgende:
Dit is het zeker niet. Een quote van Rik van Riel waarom je nog steeds veel swap nodig hebt als je meer RAM in je systeem zet:
[..rik-van-riel-verhaal..]
In een oudere thread schreef ik in discussie met deadinspace al eens:
[..oude-thread-verhaal..]

ik vind persoonlijk dat je niet dingen in swap en mem mag zetten - was mij idd. ook al eens opgevallen maar op veel computers zal steeds andere data in de mem/swap staan en moet je dus steeds andere data naar swap verhuizen. Dus vooral op "busy" en "data-changing" computers lijkt mij dit niet ideaal. Maar goed, Rik van Riel heeft hier natuurlijk veel meer verstand van dan ik.

Echter, dat is niet waarom ik swapoff() zo slecht vind.

swapoff() nam tot 2.4.5 (toen waren de allermooiste discussies (a.k.a. flames) op linux-kernel) de gehele CPU in gebruik en ging vrolijk door totdat ie klaar was. Kon je dus gerust een uurtje of wat achteruit leunen want je compu werd onbruikbaar.

Waar het mij om gaat is dat je per situatie moet bekijken welke data "minder gebruikt" wordt of "minder nodig is" en daarom dat "on-the-fly", dus terwijl de compu runt en bruikbaar is, naar de swap verhuist (en weer terug). Daar een kernel niks van userspace hoort af te weten vind ik dat dit een background daemon hoort te zijn (die zal ik kswapd noemen ), niet een kernel function. Een daemon weet namelijk meer van userspace af dan een kernel. Daarnaast is het voor een daemon een "automatisch iets" dat het op de achtergrond runt terwijl de rest van het leven doorgaat. Voor een kernel function is dat niet het geval. Vanaf 2.4.6 (geloof ik) werd dit opgelost door middenin swapoff() een functie te zetten die kijkt of er nog meer te doen is.... Dat is er dus gewoon ingehackt, de slechtst mogelijke methode om dit te doen. Vind ik absoluut niet verantwoord voor een stable kernel - dat verdient een veel mooiere oplossing. Nogmaals, ik heb er minder verstand van dan zij en zij ehbben ongetwijfeld goede redenen om de oplossing te nemen die ze hebben genomen maar architecturisch gezien vind ik de gekozen oplossing, swapoff(), de slechtst mogelijke.... Een kswapd-daemon zou veel mooier zijn geweest.

Doe ik... Heb hier ook al eerder discussies over gehad op GoT. Dat patches die er niet horen zomaar worden aangenomen lijkt me stug. Iedere developer die iets van het onderwerp weet kan dan zien dat de patch geen verbetering is en een andere schrijven of vertellen waarom de patch er niet in moet.

Hij werkte voor sommigen en dus werd 2.4.5 uitgebracht. Toen bleek dat ie voor anderen niet werkte Maar dan is het al te laat want 2.4.5 is er al.... Dat was het probleem. En niet iedere developer kan natuurlijk in een oogopslag zien of een patch wel of niet werkt - zo'n patch had uitvoeriger getest moeten worden - dit was net eventjes te snel....

Nouja goed, vat dit niet op als flame richting de kernel developers want ik heb respect voor hun werk en zou het niet beter kunnen, vrees ik

[odysseus]

Op maandag 27 augustus 2001 10:28 schreef beelzebubu het volgende:

[..]

swapoff() nam tot 2.4.5 (toen waren de allermooiste discussies (a.k.a. flames) op linux-kernel) de gehele CPU in gebruik en ging vrolijk door totdat ie klaar was. Kon je dus gerust een uurtje of wat achteruit leunen want je compu werd onbruikbaar.

Mee eens, dat was gewoon een grove fout. Heb er zelf toen ook een keer last van gehad.

Waar het mij om gaat is dat je per situatie moet bekijken welke data "minder gebruikt" wordt of "minder nodig is" en daarom dat "on-the-fly", dus terwijl de compu runt en bruikbaar is, naar de swap verhuist (en weer terug). Daar een kernel niks van userspace hoort af te weten vind ik dat dit een background daemon hoort te zijn (die zal ik kswapd noemen ), niet een kernel function. Een daemon weet namelijk meer van userspace af dan een kernel. Daarnaast is het voor een daemon een "automatisch iets" dat het op de achtergrond runt terwijl de rest van het leven doorgaat. Voor een kernel function is dat niet het geval. Vanaf 2.4.6 (geloof ik) werd dit opgelost door middenin swapoff() een functie te zetten die kijkt of er nog meer te doen is.... Dat is er dus gewoon ingehackt, de slechtst mogelijke methode om dit te doen. Vind ik absoluut niet verantwoord voor een stable kernel - dat verdient een veel mooiere oplossing. Nogmaals, ik heb er minder verstand van dan zij en zij ehbben ongetwijfeld goede redenen om de oplossing te nemen die ze hebben genomen maar architecturisch gezien vind ik de gekozen oplossing, swapoff(), de slechtst mogelijke.... Een kswapd-daemon zou veel mooier zijn geweest.

Wel, ik neem aan dat je weet dat kswapd al bestaat Bij mijn weten staat de 'd' aan het eind van kswapd nog altijd voor 'daemon', dus alhoewel ik over het hele ding weinig weet neem ik maar aan dat dat in ieder geval goed zit. Dat een kernel-functie niet de hele tijd zou kunnen draaien is niet helemaal kloppend en zeker in het geval van een VM denk ik dat die niet als (userspace) deamon thuishoort. Al was het maar omdat ie dan zijn eigen memory niet meer kan allocaten...
Dat ze die functie in swapoff() hebben gezet is misschien niet de mooiste oplossing, maar ik denk dat dat *juist* is omdat we in een (veronderstelde) stable version zitten. Daar ga je geen API-wijzigingen in aanbrengen zolang het niet echt nodig is dan is het implementeren van een functie in de al aanwezige swapoff()-functie waarschijnlijk niet de beste qua design, maar wel een niet al te pijnlijke oplossing. Waarschijnlijk worden dergelijke dingen al weer vrij snel omgegooid als de 2.5-lijn eenmaal aan de gang is.

Nouja goed, vat dit niet op als flame richting de kernel developers want ik heb respect voor hun werk en zou het niet beter kunnen, vrees ik

Insgelijks Overigens zou iedereen wel prima kunnen helpen. Vorige week had er iemand een patch geschreven waarmee je via parameters in /proc zelf de pache-aging tactieken kon instellen en zo testen bij welke workloads welke tactiek de beste is. Op die manier valt de VM in ieder geval te fine-tunen, al verandert het weinig aan het design. Was best een interessante patch en ik zit er aan te denken om het eens te proberen, maar ja...de scholen beginnen morgen weer...

* odysseus is ook maar een 15-jarig jochie dat niet eens echt kan programmeren en maar wat zinnigs probeert uit te kramen...hopend dat hij niet al te vervelend is...

[Verwijderd]

Op maandag 27 augustus 2001 13:00 schreef odysseus het volgende:
Wel, ik neem aan dat je weet dat kswapd al bestaat Bij mijn weten staat de 'd' aan het eind van kswapd nog altijd voor 'daemon', dus alhoewel ik over het hele ding weinig weet neem ik maar aan dat dat in ieder geval goed zit.`

Dat weet ik (hoe kom ik anders aan die naam ), maar die doet niet helemaal wat ik zou willen dat ie zou doen

In principe betuurt (denk ik) kswapd het mem-gebruik. Als dit te hoog is dan wordt de kernel gesommeerd om te gaan swapoff()-en, en juist dit vind ik rampzalig - ik vind dus dat je dan vanuit kswapd moet kijken in hoeverre welk gedeelte van het geheugen moet worden geswapped. Dat kan je mijns inziens vanuit userspace regelen en dan een soort mini-swapoff() in de kernel houden die "stukjes mem in swap kan zetten", en kswapd regelt dan dus welke gedeeltes dat moeten zijn.

Dat een kernel-functie niet de hele tijd zou kunnen draaien is niet helemaal kloppend en zeker in het geval van een VM denk ik dat die niet als (userspace) deamon thuishoort. Al was het maar omdat ie dan zijn eigen memory niet meer kan allocaten...

malloc(), toch?

* odysseus is ook maar een 15-jarig jochie dat niet eens echt kan programmeren en maar wat zinnigs probeert uit te kramen...hopend dat hij niet al te vervelend is...

Valt wel mee hoor

[odysseus]

Op maandag 27 augustus 2001 13:53 schreef beelzebubu het volgende:

[..]

Dat weet ik (hoe kom ik anders aan die naam ), maar die doet niet helemaal wat ik zou willen dat ie zou doen

In principe betuurt (denk ik) kswapd het mem-gebruik. Als dit te hoog is dan wordt de kernel gesommeerd om te gaan swapoff()-en, en juist dit vind ik rampzalig - ik vind dus dat je dan vanuit kswapd moet kijken in hoeverre welk gedeelte van het geheugen moet worden geswapped. Dat kan je mijns inziens vanuit userspace regelen en dan een soort mini-swapoff() in de kernel houden die "stukjes mem in swap kan zetten", en kswapd regelt dan dus welke gedeeltes dat moeten zijn.

Het zou zeker mooi zijn als je precies weet welke stukken mem je zometeen weer nodig hebt en welke niet, en zeker als je dat vanuit userspace zou kunnen zien. Om te weten welke dingen je moet gaan uitswappen en welke je nog moet bewaren in je RAM zijn verschillende tactieken. Zo worden in de huidige implementatie dingen die een keer zijn ingebracht, maar daarna niet snel nog een keer worden gelezen verondersteld binnenkort niet nodig te zijn en dus uitgeswapt. Men gebruikt hiervoor page-aging, een soort lijsten van pages die in een soort wedstrijdje steeds stijgen en dalen: als de pagina gebruikt wordt, gaat hij omhoog, wordt hij een rondje niet gebruikt, dan zakt hij. Als hij onderaan belandt wordt hij in de inactive-list gezet, die hem kan uitswappen. Dat is wat ik ervan begrijp althans. Ik heb mijn twijfels of een userspace daemon zoiets zou kunnen doen, maar als het kan is dat waarschijnlijk de beste oplossing.

[..]



malloc(), toch?

Err...waarschijnlijk was ik niet goed wakker, ik denk dat je gewoon gelijk hebt.

[..]



Valt wel mee hoor

Gelukkig...

[Verwijderd]

Op maandag 27 augustus 2001 14:50 schreef odysseus het volgende:
[...]
Ik heb mijn twijfels of een userspace daemon zoiets zou kunnen doen, maar als het kan is dat waarschijnlijk de beste oplossing.

Als je een daemon als kswapd gebruikt dan kan die informatie van kernel- en userspace delen. Dan kan het. Een userspace proggie kan niet uit zichzelf ff de page-count bijhouden, nee

Uiteindelijk kom je toch op een kernel-/user-gedeelde oplossing uit, vrees ik

Err...waarschijnlijk was ik niet goed wakker, ik denk dat je gewoon gelijk hebt.

[RG]

Ik heb het ooit eens gehad dat mijn RAM en swap voor 100% vol zat. Ik ging gewoon eens ff een heel groot level testen in UT met de S3TC textures (2048x2048 pixels) met 16 spelers. Op een gegeven moment trekt ie het niet meer en toen zat op een gegeven moment al het geheugen vol (ram en swap).
UT was niet meer vooruit te branden, harde schijf flipte, maar het systeem liep absoluut niet vast. Gewoon killen die handel en had weer bijna al mijn Ram en Swap vrij (20MB ram gebruikt ofzo)

[odysseus]

Op maandag 27 augustus 2001 22:34 schreef Groot-Moefti het volgende:
[..]
UT was niet meer vooruit te branden, harde schijf flipte, maar het systeem liep absoluut niet vast. Gewoon killen die handel en had weer bijna al mijn Ram en Swap vrij (20MB ram gebruikt ofzo)

Dat is ook wat er moet gebeuren. Helaas hadden oudere kernels hier nog wel eens moeite mee. In de 2.4-reeks werkt de OOM-killer (OOM = Out Of Memory) prima, voor zover ik tot nog toe heb kunnen constateren. In 2.2.19pre1 en eerder had je nog errors a la "do_try_free_pages for <process_name> failed", dat is nu ook opgelost.

[Verwijderd]

Op dinsdag 28 augustus 2001 13:35 schreef odysseus het volgende:

[..]

Dat is ook wat er moet gebeuren. Helaas hadden oudere kernels hier nog wel eens moeite mee. In de 2.4-reeks werkt de OOM-killer (OOM = Out Of Memory) prima, voor zover ik tot nog toe heb kunnen constateren. In 2.2.19pre1 en eerder had je nog errors a la "do_try_free_pages for <process_name> failed", dat is nu ook opgelost.

Die had een hele andere reden, die had hier weinig mee te maken

En dan nog, hij killt niet, hij swapoff()t alleen, en dat neemt je CPU in beslag. Er wordt verder niks gekillt, alleen geblockt omdat kernel voorrang krijgt.

Een goede kernel met goede mem-management heeft helemaal geen OOM killer nodig, bovendien

[odysseus]

Op dinsdag 28 augustus 2001 14:08 schreef beelzebubu het volgende:

[..]



Die had een hele andere reden, die had hier weinig mee te maken

En dan nog, hij killt niet, hij swapoff()t alleen, en dat neemt je CPU in beslag. Er wordt verder niks gekillt, alleen geblockt omdat kernel voorrang krijgt.

Een goede kernel met goede mem-management heeft helemaal geen OOM killer nodig, bovendien

Hmm, niet helemaal duidelijk gemaakt dat ik twee aparte dingen bedoelde (OOM en do_try_free_pages).
Overigens wil ik wel eens weten hoe een kernel het wil gaan regelen als hij meer informatie moet opslaan dan hij aan ruimte heeft. Dan zal hij toch wat weg moeten gooien: OOM-killer. Als mem en swap echt vol zitten helpt daar geen enkel management meer aan, dan is het gewoon puinruimen. Lijkt mij in ieder geval.

[Verwijderd]

Op dinsdag 28 augustus 2001 14:27 schreef odysseus het volgende:

[..]

Hmm, niet helemaal duidelijk gemaakt dat ik twee aparte dingen bedoelde (OOM en do_try_free_pages).
Overigens wil ik wel eens weten hoe een kernel het wil gaan regelen als hij meer informatie moet opslaan dan hij aan ruimte heeft. Dan zal hij toch wat weg moeten gooien: OOM-killer. Als mem en swap echt vol zitten helpt daar geen enkel management meer aan, dan is het gewoon puinruimen. Lijkt mij in ieder geval.

Geheugen wordt ge-allocate met malloc(). Als malloc() dus geen memory meer kan vinden dan returnt ie (geloof ik) NULL -> geen memory.

code:

char *p = (char *) malloc(sizeof(char)*32);
if (!p) {
  printf("Error: out of mem\n");
  exit(1);
}

Als een proggie zelf wordt gestart en er is neit genoeg geheugen, dan wordt het proggie niet gestart en zal (in het geval van een c-proggie) libc main() niet uitvoeren - dat zie je dan wel in je terminal (libc geeft een foutmelding).

[Sjonny]

dat is niet helemaal wat ik op mijn werk heb meegemaakt met een FreeBSD bak (geen linux dus eh!)..
die computer had maar 32Mb RAM en 32Mb swap, dus je had er vaak last van. als je zit te werken starten programma's idd niet op, maar als ik de volgende dag terug kwam en ik had kde aan laten staan wassie vrolijk weg omdat waarschijnlijk cron voorang op het geheugen kreeg... X mocht ik dan fijn overnieuw starten ...
ik heb linux niet echt lopen stressen dat er geen memory meer was, en als er een mem leak me bak op vrat en het nog uren ging duren, had ik allang de rest knop gevonden geen moeite mee. natuurlijk niet de beste oplossing, zeker als het een server is niet, maar je hdd voor een paar uur laten gorgelen heb ik geen behoefte aan

[deadinspace]

Op dinsdag 28 augustus 2001 16:02 schreef beelzebubu het volgende:
Geheugen wordt ge-allocate met malloc(). Als malloc() dus geen memory meer kan vinden dan returnt ie (geloof ik) NULL -> geen memory.

malloc() returnt NULL alsie nix kan alloceren ja. Maar malloc() is een functie van de dynamic memory allocating code uit libc; libc vraagt dan weer (grotere stukken) ram aan de kernel. De kernel gebruikt dus zeker geen malloc().

code:

char *p = (char *) malloc(sizeof(char)*32);
if (!p) {
  printf("Error: out of mem\n");
  exit(1);
}

Als een proggie zelf wordt gestart en er is neit genoeg geheugen, dan wordt het proggie niet gestart en zal (in het geval van een c-proggie) libc main() niet uitvoeren - dat zie je dan wel in je terminal (libc geeft een foutmelding).

Ehm, nee, dan gaat de shell zeuren meen ik - deze voert immers een fork() en een exec() uit.

Maar kernel != progje. De kernel is kernelspace, de kernel heeft altijd gelijk, de kernel is absoluut. Als de kernel ram nodig heeft is 'er is niet genoeg' geen optie, dus maait hij wat af (OOM).

Als een programma meer geheugen request dan er is, dient hij dat geheugen niet te krijgen, of het programma moet afgemaaid worden.In de 2.2 serie ging dat nogal eens fout, omdat als programma A dan geheugen requestte, werd programma B afgemaaid - geen ideale situatie.

Maar dit heeft vrij weinig betrekking op de problemen met de huidige VM. De problemen met de 2.4 VM zijn vooral het swap-beheer/gebruik.

[Verwijderd]

Op dinsdag 28 augustus 2001 20:11 schreef deadinspace het volgende:
malloc() returnt NULL alsie nix kan alloceren ja. Maar malloc() is een functie van de dynamic memory allocating code uit libc; libc vraagt dan weer (grotere stukken) ram aan de kernel. De kernel gebruikt dus zeker geen malloc().

kmalloc()

Maar kernel != progje. De kernel is kernelspace, de kernel heeft altijd gelijk, de kernel is absoluut. Als de kernel ram nodig heeft is 'er is niet genoeg' geen optie, dus maait hij wat af (OOM).

Dat de kernel de app mag/kan afmaaien wist ik. Dat dat policy was wist ik niet.... Weer wat geleerd

[deadinspace]

Mja, als de kernel ergens wat ram voor nodig heeft, en dat is er niet (en hij kan niets met de buffers/caches verkleinen doen), dan gaan er dingen goed fout gok ik, dus dan moet er maar geheugen vrijgemaakt worden...