Parmi les améliorations notables :
- Meilleure gestion de la Memoire virtuelle
- Amélioration de l'intégration des systèmes de fichiers journalisés
- Grosse mise à jour des drivers
- Amélioration de la prise en compte de l'USB
Nota : Il semblerait que ce noyau, contrairement aux précédents de la série 2.4.x, permet enfin d'éviter un swapping monstre de la machine. Ce serait la première fois depuis la sortie de la série 2.4.x que la gestion mémoire soit enfin "acceptable".
Aller plus loin
- Changelog (4 clics)
- Ftp en France (2 clics)
- Mirroirs (2 clics)
# Bonjour, je viens foutre la merde
Posté par Anonyme . Évalué à -10.
Et la paf, ca a pas tenu 24 heures comme resolutions. Ce site n'a décidement aucune vision, aucune politique éditoriale, et fait n'importe quoi.
[^] # Re: Bonjour, je viens foutre la merde
Posté par vrm (site web personnel) . Évalué à 10.
c'est un nouvelle très importante !
[^] # Re: Bonjour, je viens foutre la merde
Posté par loopkin . Évalué à 2.
[^] # Le swap du 2.4.10
Posté par Anonyme . Évalué à 10.
Mes quelques tests brutaux me font dire qu'il y a une véritable amélioration par rapport au 2.4.9
et plus encore par rapport au 2.4.4 (qui était le pire pour la VM).
[^] # Re: Bonjour, je viens foutre la merde
Posté par un nain_connu . Évalué à 10.
[pastis:~] $ uptime
10:44:21 up 10:33, 2 users, load average: 0.08, 0.06, 0.01
[pastis:~] $ free
total used free shared buffers cached
Mem: 191676 177808 13868 0 1840 43808
-/+ buffers/cache: 132160 59516
Swap: 120452 0 120452
[^] # Re: Bonjour, je viens foutre la merde
Posté par Sebastien (site web personnel) . Évalué à 4.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Anonyme . Évalué à -8.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Vanhu . Évalué à -3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Attention message URGENT
Posté par Anonyme . Évalué à -3.
[^] # please
Posté par Anonyme . Évalué à 10.
..................................___________________...
........................../|../|..|..................|..
..........................||__||..|......Please.do...|..
........................./...O.O\__.........NOT......|..
......................../..........\.......feed......|..
......................./......\.....\...the.trolls...|..
....................../..._....\.....\.______________|..
...................../....|\____\.....\.....||..........
..................../.....|.|.|.|\____/.....||..........
.................../.......\|_|_|/...|....__||..........
................../../..\............|____|.||..........
................./...|...|./|........|......--|.........
.................|...|...|//.........|____..--|.........
..........*._....|..|_|_|_|..........|.....\-/..........
.......*--._--\._.\.....//...........|..................
........./.._.....\\._.//...|......../..................
.......*../...\_./-.|.-.....|.......|...................
.........*......___.c_c_c_C/.\C_c_c_c____________.......
[^] # Re: please
Posté par Anonyme . Évalué à -1.
[^] # Re: please
Posté par Brice Favre (site web personnel) . Évalué à 4.
[^] # Re: please
Posté par Henri . Évalué à -2.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Yusei (Mastodon) . Évalué à -1.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Brice Favre (site web personnel) . Évalué à -2.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Jiquem . Évalué à -2.
[^] # Re: Bonjour, je viens foutre la merde
Posté par Anonyme . Évalué à -1.
# sauvons la bande passante
Posté par Anonyme . Évalué à 1.
[^] # Re: sauvons la bande passante
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
[^] # Re: sauvons la bande passante
Posté par Anonyme . Évalué à 5.
[^] # Re: sauvons la bande passante
Posté par Corsaire . Évalué à 3.
A ce sujet je pose d'ailleurs la question suivante ...
Pourquoi n'a t'on pas de ***.tar.bz2 sur le serveur lip6 ?
Non seulement ca ferait gagner de la bande passante car le temps de chargement pour chaque utilisateur serait reduit mais en plus ca economiserais de la place ...
Pour le cas du 2.4.10 on passe de 28Mo a 21Mo...
Je prefere de loin telecharger sur un serveur FR comme lip6 pas par chauvinisme mais la je sais que j'ateind minimum 60K/s en toute circonstances (fait ce matin quand je l'ai pompe le fameux noyau ;).
# Des infos précises
Posté par matiasf . Évalué à 10.
Quelques explications STP. car je ne savais pas que le noyau 2.4 avait ce problème. Conseil : regarde /proc/sys.
Si le noyau 2.4 parait consommer plus de swap que le 2.2, c'est NORMAL. Par exemple, le swap n'est désalloué que sur nécessité. Donc si un gros programme est lancé et qu'il prendre, par exemple , 128Mo de swap, lorsque le programme sera arrêté, le swap ne sera pas forcément immédiatement désalloué.
> Ce serait la première fois depuis la sortie de la série 2.4.x que la gestion mémoire soit enfin "acceptable".
"acceptable", veut dire que l'on a atteint le niveau de windows 2000 ?
Plus sérieusement, la gestion mémoire est plus qu'"acceptable". Par exemple, la gestion mémoire du 2.4 a été backporté sur le 2.2 (le 2.2.18 ou 2.2.19) ce qui prouve sa faibilité (même s'il y a encore quelques problèmes).
Quant on considère le délais de sortie du noyau 2.4 (les 2.4.0pre...) et qu'à la version 2.4.10 (8 mois après la 2.4.0) on lit :
<<la gestion mémoire soit enfin "acceptable".>>
sans le moindre argument.
Et bien je dis que c'est du TROLL.
Si quelqu'un a des infos sur ce problème de swap et depuis quand il existe, je suis preneur.
[^] # Re: Des infos précises
Posté par Mokona . Évalué à 7.
De même, il me semble que sur le traitement de gros fichiers, ça ramouillait aussi (quand je dis gros, ce sont des logs de 50-300Mo).
Enfin tout ça, c'est du souvenir un peu brumeux comme je disais, pas des infos techniques.
[^] # Re: Des infos précises
Posté par loopkin . Évalué à -1.
[^] # Re: Des infos précises
Posté par Jerome Demeyer . Évalué à 4.
Faut lire les ChangeLog :)
[^] # Re: Des infos précises
Posté par loopkin . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des infos précises
Posté par Anonyme . Évalué à -3.
[^] # Re: Des infos précises
Posté par Corsaire . Évalué à 4.
Vous pouvez lui rendre une petite visite a l'URL suivante http://www.uow.edu.au/~andrewm/linux/ext3/(...)
"le bouton rouge s'appuie toujours plus vite..."
[^] # Ext3 bien vu par RedHat
Posté par JSL . Évalué à 5.
ftp://ftp.redhat.com/pub/redhat/linux/beta/(...)
roswell/en/os/i386/RELEASE-NOTES
De même chez Mandrake (même si je ne peut dire si son usage en sera automatisé au niveau de l'interface d'installation) :
http://www.linux-mandrake.com/fr/81rc.php3(...)
Ceci étant dit, son support par le kernel «officiel» ne devrait tarder.
[^] # Re: Ext3 bien vu par RedHat
Posté par loopkin . Évalué à 0.
[^] # Re: Des infos précises
Posté par matiasf . Évalué à -1.
C'est vieux çà (problème avec syslog principalement). De l'époque du 2.0 il me semble et assez rapidement corrigé.
[^] # Re: Des infos précises
Posté par PLuG . Évalué à 7.
Sinon quoi ?
je fait tourner des kernel 2.4 sur plusieurs machines et peu ont cette taille de swap.
Pourtant elles fonctionnent bien.
C'est ce genre d'info sans fondement qui polu les nouvelles techniques. Alors je continue :-))
Petit rappel de mémoire:
lors de la sortie du 2.4, il a été annoncé que ce kernel consommait plus de swap que les précédents... et que du coup il était conseillé de dimensionner le swap à au moins 2 fois la taille de la RAM, surtout que le kernel n'AIME VRAIMENT PAS être à cour de swap.
Néanmoins, sur une machine avec suffisement de RAM pour son utilisation normale, le swap n'est JAMAIS completement utilisé et on peut le dimensionner comme on veut.
--fin de l'expérience personnelle--
l'important c'est d'avoir autant de swap que necessaire, pas n fois la taille de la RAM
réjouissons-nous tout de même si amélioration il y a eu sur le 2.4.10 !!
[^] # Re: Des infos précises
Posté par kadreg . Évalué à 0.
la première fois que j'ai lu ce truc, c'est dans le livre de Matt Welsh. Donc ca fait un sacré bout de temps, puisque il était basé sur les noyaux 1.0 ou 1.2 (je sais plus, ca fait longtemps).
Depuis cette époque, cette partie du noyau (la VM) a du être réécrite deux ou trois fois, donc ca ne doit vraiment plus être d'actualité.
[^] # Re: Des infos précises
Posté par boubou (site web personnel) . Évalué à 10.
Autre source : http://kt.zork.net/kernel-traffic/kt20010330_113.html#6(...) avec des explications de Rik Van Riel himself. En gros, le code de récupération des zones non utilisées du swap a été supprimé sur 2.4 et donc, il faut respecter la règle du 2 fois la RAM.
[^] # Re: Des infos précises
Posté par PLuG . Évalué à 1.
Je ne suis toujours pas d'accord.
Rik Van Riel explique bien que le kernel de récupère pas l'espace de swap plus-utilisé lors des opérations de swap-in. Il écrit clairement que du coup les infos peuvent être dupliquées, une fois en RAM et une fois dans le swap.
et alors ?
cela ne fait que confirmer ce que je disais plus haut: le kernel 2.4 est potentiellement plus gourmand en swap que le 2.2
Il sera plus gourmand a ces conditions:
1/ il swappait deja avec le 2.2
2/ les pages swappées ne sont pas toujours les même. autrement dit soit la machine fait tourner plusieurs process gourmand en RAM, soit, pire, elle fait tourner des jobs qui manipulent des données immenses en RAM (en pseudo RAM en fait puisque les données ne tiennent pas en RAM -- elles sont swapées).
En clair, la RAM est clairement sous dimensionnée.
Enfin, a titre de démonstration, on pourrait très bien écrire un process qui utilise une quantité de swap bien supérieure à cette limite empirique de 2 x RAM.
L'avis de Linus (cf le lien que tu donnes) est clairement que de toutes facons il faut acheter de la RAM si cela swap trop. "trop" c'est subjectif, mais personnellement j'acheterai des barettes avant de remplir 2x RAM de swap [sauf cas exceptionnels genre batch sur machine dédiée ?]
[^] # Re: Des infos précises
Posté par Obsidian . Évalué à 4.
Personnellement, je me suis amusé à faire un swapoff avec xosview ouvert, et à ouvrir des xterms pour saturer la mémoire. Ben il tient ses promesses.
Pas de différence notable dans l'utilisation des applis déjà ouvertes. Je crois que quand la situation est vraiment critique, il ferme proprement les processus dans l'ordre de leur importance (je sais pas comment il les choisit: RAM utilisée, idle time ...). C'est une bonne chose d'ailleurs parce que le crash du disque qui héberge le swap est toujours à envisager (l'avantage, c'est qu'il n'y a pas de réelle perte de données).
Y a certains OS qui crasheraient rien qu'à la fermeture de leur swap !
[^] # Re: Des infos précises
Posté par Mes Zigues . Évalué à -3.
scoré à -1
[^] # Re: Des infos précises
Posté par Obsidian . Évalué à 2.
swapoff sert à çà, et fonctionne bien (must be root, tought).
Sorti de là, il me semble bien que l'on peut le faire sous Windows aussi sans avoir à rebooter, non ?
[^] # Re: Des infos précises
Posté par oliv . Évalué à 8.
>il était conseillé de dimensionner le swap à au moins 2 fois la taille de la RAM
Selon Alan Cox, il n'était pas conseillé, mais fortement suggéré (En gros : "ne venez pas vous plaindre si votre système plante, c'est écrit qu'il faut au moins 2 fois la RAM!"). En vrai, de mémoire, c'était même obligatoire pour lui.
Mais ce prérequis est de l'histoire ancienne, depuis le 2.4.8:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.2/0056.html(...)
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.2/0071.html(...)
[^] # Re: Des infos précises
Posté par oliv . Évalué à 5.
"Linus said 2.4.0 would need more swap than ram when he put out 2.4.0."
( http://uwsg.iu.edu/hypermail/linux/kernel/0105.3/1043.html(...) )
"Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap with 2.4.
Marcelo is working to change that but right now you are running something explicitly explained as not going to work as you want"
( http://uwsg.iu.edu/hypermail/linux/kernel/0105.3/1498.html(...) )
[^] # Re: Des infos précises
Posté par oliv . Évalué à 10.
http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html(...)
ou
http://www.geocrawler.com/lists/3/Linux/35/0/(...)
ou le Kernel Traffic pour un résumé
http://kt.zork.net/kernel-traffic/index.html(...)
Enfin, l'excellent résumé hebdomadaire de Linux Weekly News mentionne de manière récurrente le problème autour de la gestion de la mémoire.
http://lwn.net/2001/0920/kernel.php3(...)
A noter que les Kernel d'Alan Cox semblaient être moins sensibles au problème que ceux de Linus, et que les 2 branches ayant convergé à nouveau (le 2.5 sera lancé quand les deux branches ne feront plus qu'une ou que les différences seront mineures), le kernel de Linus devient meilleur.
[^] # Re: Des infos précises
Posté par matiasf . Évalué à 1.
[^] # Re: Des infos précises
Posté par oliv . Évalué à 6.
Par ailleurs, si la gestion mémoire était "acceptable" pour Linus, il n'aurait pas fait de tels changements au kernel "stable". Il a reçu des critiques sur l'importance des changements, que certains auraient préféré voir dans le 2.5.
Quelques autres avis (attention, les prendre avec retenue, ils viennent de la LKML, parfois, ça trolle un peu, même eux ;) ):
Andrea Arcangeli (le 18 septembre):
"Critical servers with very high vm loads still have to run 2.2 to be stable and fast unfortunately."
"the true mess is the 2.4 VM before 2.4.10pre11. Period."
Rik van Riel(le 19 septembre):
"If you want a stable kernel, use Alan's kernel."
On peut presque ajouter ça aux "fortunes" :)
[^] # Re: Des infos précises
Posté par Anonyme . Évalué à 1.
Le kernel de Linus est devenu meilleur grace a des modifs dans la VM qui ne sont pas dans la -ac mais de Linus, Andrea et d'autres.
Voir les lkml
[^] # Re: Des infos précises
Posté par boubou (site web personnel) . Évalué à 10.
Il y avait aussi des problèmes avec l'algorithme qui temporise les écritures sur disque (le cache disque, quoi) qui a visiblement des intéractions subtiles avec la VM (http://lwn.net/2001/0809/kernel.php3(...) ).
Il semblerait bien que pas mal de gens râlent à mort sur la VM depuis le début du 2.4 puisqu'un des développeurs s'est senti obligé de pondre une explication sur les buts de la VM (http://lwn.net/2001/0628/kernel.php3(...) ). Un résumé des problèmes avait été posté fin mai sur lwn (http://lwn.net/2001/0531/kernel.php3(...) ).
A mon avis, l'idéal pour comprendre les problèmes de VM sous linux est de lire l'article du hacker de choc Rik van Riel : http://www.surriel.com/lectures/linux24-vm.html(...)
D'ailleurs, pour vraiment suivre l'actualité de la gestion mémoire sous linux, le mieux est sûrement d'aller fouiner sur le site qui lui est consacré http://linux-mm.org/(...)
Si on résumé, le noyau 2.2 marchait plutôt pas mal, mais il y avait visiblement des problèmes de montée en charge et de gestion des grosses mémoires. Certaines modifications ont été faites pour améliorer tout ça dans le 2.4, ce qui a produit un noyau moins bon pour la gestion mémoire au début. Normalement, le noyau actuel marche aussi bien que le 2.2, mais sans avoir les problèmes répérés dans ce-dernier, ce qui signifie que le 2.4 devrait marcher aussi bien et parfois mieux en toutes circonstances.
[^] # Re: Des infos précises
Posté par Anonyme . Évalué à 3.
Il est évident que "acceptable" est relatif à la qualité que l'on attend d'un noyau Linux stable. Le 2.4 a bien eu les problèmes évoqués, tout le monde le reconnait (y compris parmi les développeurs du noyau). C'est pour ça qu'il est toujours conseillé pour les machines critiques d'utiliser un 2.2.19 (à moins que le 2.4.10 convienne maintenant).
Cela n'empeche pas ce 2.4 d'etre un bon noyau, d'apporter beaucoup de choses, et d'etre largement acceptable pour un usage personnel.
[^] # Re: Des infos précises
Posté par Olivier Jeannet . Évalué à 2.
D'où tiens-tu cette information ?
Il y a des choses qui ont été backportées du 2.4 vers le 2.2 mais il s'agit plutôt de l'USB ou du DRI, dans le 2.2.18 .
Par ailleurs "oliv" a parfaitement répondu à ton doute concernant les problèmes persistants de VM dans le 2.4 .
[^] # Re: Des infos précises
Posté par matiasf . Évalué à 4.
Dans mon post, j'ai mis "même s'il y a encore quelques problèmes". Donc je sais qu'il y a des problèmes. Je trouve simplement que ces problèmes ne peuvent ammener à considérer les noyaux < 2.4.10 comme ayant une gestion mémoire inacceptable. C'est tout. Ou alors, que penser des utilisateurs des noyaux 2.4, des fabricants de distribue le noyaux 2.4 (même pour un usage serveur), etc...
>> la gestion mémoire du 2.4 a été backporté sur le 2.2 (le 2.2.18 ou 2.2.19)
> D'où tiens-tu cette information ?
Pas totalement backporté.
http://lwn.net/2000/1214/kernel.php3(...)
Il faudrait fouillé dans la mailing du kernel. En gros, il y des parties reprise du noyau 2.4. Par exemple, il n'y a plus deux parties pour la gestion mémoire (comme au début du 2.2).
Un exemple tout bête, est :
$ cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 200900608 139653120 61247488 0 7012352 55255040
Swap: 271425536 39514112 231911424
MemTotal: 196192 kB
MemFree: 59812 kB
MemShared: 0 kB
Buffers: 6848 kB
Cached: 53960 kB
BigTotal: 0 kB
BigFree: 0 kB
SwapTotal: 265064 kB
SwapFree: 226476 kB
Shared est toujours 0 avec le 2.2.19 (je suis sous 2.2.20pre9 plus patch andrea (pour périphérique raw), ide, i2c etc...). Alors d'avec le 2.2.18 shared n'étant pas à 0.
[^] # Re: Des infos précises
Posté par Anonyme . Évalué à 0.
bozo@local:~# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 363003904 170975232 192028672 172212224 15716352 78221312
Swap: 139788288 0 139788288
MemTotal: 354496 kB
MemFree: 187528 kB
MemShared: 168176 kB
Buffers: 15348 kB
Cached: 76388 kB
SwapTotal: 136512 kB
SwapFree: 136512 kB
[^] # Re: Des infos précises
Posté par matiasf . Évalué à 2.
J'utilise Redhat 6.2. J'ai deux noyaux, un pour le boulot et un pour la maison. Pour le boulot c'est le noyau officiel RedHat (2.2.19-6.2.7) avec environ 80 patchs (dont andrea, mais pas un 100% 2.2.19).
Pour un usage personnel j'ai un :
2.2.19
+ pre-patch 2.2.20pre9 (ac)
+ 2.2.20pre9aa2 (andrea)
+ d'autres mais pas liés à la VM
Je comfirme la tendance 2.4 (ou andrea) de la VM pour le 2.2.19 :
http://lwn.net/2000/1221/a/2.2.19pre2.php3(...)
Mais, et je m'en excuse, je n'ai pas trouvé d'éléments qui le dit clairement (le premier post était fait de mémoire sans controler). Et pour rappel, j'ai indiqué "Pas totalement backporté".
Enfin, la prochaine fois je recherche des éléments costauds avant de faire un post.
[^] # Re: Des infos précises
Posté par Loic Jaquemet . Évalué à 4.
j'ai un noyau 2.4.8 ( c'etait pareil pour tout les 2.4 ) ..
J'ai 641 Mo de ram .
quand je force mon os a essayer de les utiliser :
mon occupation RAM monte tres rapidement pour se planquer dans les buffers et le cache .
du coup les allocations sont souvent faites tres rapidement en swap .
moi je n'aime pas avoir 400 Mo de cache qui ne servent pas .
La .
[^] # Re: Des réponses précises
Posté par PLuG . Évalué à 9.
Néanmoins, depuis l'avènement du filesystème /proc, il y a des paramètres que l'on peut modifier à chaud, dynamiquement. et cela concerne aussi le tuning de la vm
Je te conseille donc de faire un tour dans /proc/sys/vm et de modifier au moins dans un premier temps les % qui sont dans les pseudo-fichiers buffermem et surtout pagecache.
premier %: % mini de RAM utilisé en buffer
second %: % a partir duquel le cache est jugé moins prioritaire.Par defaut c'est 15% soit 100Mo sur ta machine.
dernier %: % maxi.Par défaut c'est 60% soit 400Mo chez toi.
lit le fichier ./Documentation/filesystemes/proc.txt dans les sources de ton noyau, il y a d'autres paramètres modifiables !!
Si tu prefere les astuces oueb, peux aller voir ici: http://lea-linux.org/admin/optimise.php3(...) ou encore la : http://linuxperf.nl.linux.org/(...) ...
[^] # Je suis surpris
Posté par Beurt . Évalué à 4.
Je ne suis pas un pro et ma machine ne subit pas de violentes charges en milieu hostile, puisque c'est une machine de bureautique (eh oui !) et au pire elle est confrontée à Gimp plein d'images de 20 Mo et StarOffice et Netscape et plein d'autres trucs en même temps...
Avant je tournais avec un 2.2.19 sur un Pentium Pro avec 128 Mo de Ram et c'est vrai que ca swappait tout le temps (surtout dans le cas évoqué plus haut).
J'a eu l'occasion de modifier un peu ma machine (Athlon et surtout 768 Mo de Ram !!!) et d'installer le kernel 2.4.3 dessus.
Bon évidement avec près de 800 Mo de Ram faut insister pour que ça swappe. Donc le swap (de 128 Mo seulement et pas de 1,6 Go !!) est toujours vide. Sauf une fois, où j'ai fait un essai: browser dans une archive de 650 Mo (sur CD) avec konqueror (et toujours StarOffice, et Gimp plein d'images derrière, hein !) et là ô surprise: Mon PC a utilisé le swap: 1Mo ! Pas plus ! Linux a tout géré dans 1 Mo de swap (plus 800 Mo mem, hein !)... J'ai été surpris et satisfait de cet test.
Vous me direz même si le prix de la Ram est bas ces jours-ci ce n'est pas forcément la solution mais mon test de charge Ram (une archive de 650Mo+ pleins d'applis en mémoire) me parait assez concluant !
C'est pourquoi je suis assez surpris de ce que je lis ici... Moi le 2.4.3 je le trouve pas mal... faudrait que j'essaie le .10 !!!
D'autant que je connais plusieurs personnes qui font tourner linux depuis un bail sur des firewalls et des serveurs (de fichiers/imprimantes & co) sans swap (avec environ 256 Mo de Ram quand même)!!! Et ils n'ont jamais eu aucun problème ! (Alors que moi du temps de mes 128 Mo et du 2.2.19 j'ai quand même eu des petits problèmes de surcharge mémoire avec Gimp (et son historique d'annulation), menant à une paralysie de la machine durant plus de 25 min avant que Gimp soit killé par le kernel !)
# Question sur le swap
Posté par kadreg . Évalué à 1.
A la maison, lors de mon install, j'ai oublié de mettre une partition de swap. Je m'en suis rendu compte plusieurs semaines après, je n'ai pas vu de signe cliniques de manque de mémoire (j'ai plein de barettes dans le PC :) ). La gestion de la memoire es-t'elle génée par cela, sachant que je reste loin de prendre toute la memoire ?
[^] # Re: Question sur le swap
Posté par Anonyme . Évalué à -1.
;-)
[^] # Re: Question sur le swap
Posté par penndu . Évalué à 1.
Ca ne sert à rien de mettre un swap en ram.
si tu a sufisemment de ram il n'est pas nécessaire de swapper pour augmenter la taille virtuelle de ta ram, ça ralentit le système
[^] # Re: Question sur le swap
Posté par matiasf . Évalué à 4.
[^] # Re: Question sur le swap
Posté par swix . Évalué à 8.
Sur mes serveurs p.ex., meme s'il y a un Go de ram, je mets quand meme 128mo de swap. Ainsi les scripts de monitoring m'avertissent assez tot quand le swap commence à se remplire, ce qui est souvent signe de probleme quelque part...
[^] # Re: Question sur le swap
Posté par Jiquem . Évalué à 0.
kelbertj@komodo:~/.kde/share/config$ free
total used free shared buffers cached
Mem: 513740 506148 7592 0 19832 298052
-/+ buffers/cache: 188264 325476
Swap: 289128 0 289128
[^] # Re: Question sur le swap
Posté par Sebastien (site web personnel) . Évalué à 1.
J'ai 2 stations là où je bosse qui ont respectivement 1Go et 1.5Go et qui pourtant ne se gênent pas pour mettre plusieurs centaines de Mo dans le swap ... Donc bon, même avec beaucoup de RAM, ce serait sympa de bien gérer le swap, quand même ...
[^] # Re: Question sur le swap
Posté par Philippe F (site web personnel) . Évalué à 2.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Linus
Posté par Anonyme . Évalué à 10.
Alan s'occupe des versions stables antérieures (2.2.x)
Alan s'occupe aussi d'une branche, disons plus ouverte aux nouveautés (et donc plus risqué), c'est les 2.4.x-acx
Enfin, les 2.5.x n'existent pas encore
[^] # Re: Linus
Posté par matiasf . Évalué à 7.
Lorsque Linus s'occupe d'une branche de developpement (par exemple 2.3), alors Alan Cox s'occupe de la dernière branche stable (2.2). Quoiqu'il en soit, il n'y a que Linus pour valider un noyau officiel. Donc pour la sortie de 2.2.19, Alan Cox l'a proposé à Linus, qui a validé (mais il peut aussi refuser), et fait l'annonce de la sortie.
[^] # Re: Linus
Posté par Anonyme . Évalué à 2.
Et 2.0.x (eh oui!). Il a sorti le 2.0.39 en juillet je crois.
[^] # Re: Linus
Posté par Miod in the middle . Évalué à 2.
[^] # Re: Linus
Posté par roland pistolero . Évalué à 4.
[^] # Re: Linus
Posté par Anonyme . Évalué à 1.
Quand la branche 2.4 sera suffisament stable, le developpement du 2.5 commencera alors.
Certains pensent que ca devrait bientot arriver: Linus et Alan 'mergent' aggressivement depuis qques temps leurs 2 branches.
[^] # Re: Linus
Posté par Anonyme . Évalué à 0.
branches
backport
maintenance
integration
...
?
[^] # Re: Linus
Posté par Anonyme . Évalué à 1.
# top chrono !!
Posté par poil oq . Évalué à -10.
[^] # Re: top chrono !!
Posté par Anonyme . Évalué à -2.
[^] # est-ce une raison pour se fâcher ?
Posté par poil oq . Évalué à -1.
cela fait deux semaines aujourd'hui
que France-Télécom me l'a fournit
sur ce mur blanc ils l'ont accroché
et moi depuis je suis scotché
les kilo-octets défilent si vite
j'ai comme qui dirait une grosse bite
même ma RedHat me remercie
elle a eu un modem ECI
[^] # Re: est-ce une raison pour se fâcher ?
Posté par Brice Favre (site web personnel) . Évalué à -1.
j'ai comme qui dirait une grosse bite
Faut eviter de trop surfer sur les sites pornos mon vieux, on av te prendre pour un terroriste.
Sinon très joli poème.
[^] # Re: top chrono !!
Posté par Anonyme . Évalué à -4.
$ time wget http://mirroirs/kernel/v2.4/linux-2.4.10.tar.gz(...)
10:54:52 (9.22 MB/s) - `linux-2.4.10.tar.gz' saved [28338216/28338216]
real 0m3.005s
[^] # Re: top chrono !!
Posté par Cru Kilu . Évalué à -10.
2 min 11 sec pour télécharger le tar.gz depuis le mirroir français, Renater RULEZ !!!
(ça fait 181 K/s, en moyenne :))))
[^] # Re: top chrono !!
Posté par matiasf . Évalué à -2.
PS. : Download le une seconde fois pour confirmer tes 3 min 46 sec. Et bien sur prend le tar.gz qui est plus gros que le tar.bz2.
[^] # Re: top chrono !!
Posté par Étienne . Évalué à 10.
La bande passante est quelquechose qui se partage et que certains mirroirs mettent gracieusement à votre disposition (par exemple proxad pour le mirroir francais). Cela permet de répartir la charge partout sur le net, mais ces mirroirs ont égallement d'autres choses à faire avec cette précieuse bande passante.
Donc pour le confort de tous, il est préférable de prendre les patch-2.4.10.bz2 et une fois placés dans le répertoire où tu as les sources du 2.4.9 (souvent /usr/src), de taper :
$ bzip2 -dc patch-2.4.10.bz2 | patch -p0
Cela arrange tout le monde (et même toi tu va gagner du temps). C'est une sorte d'acte citoyen (du net)
[^] # Re: top chrono !!
Posté par Cru Kilu . Évalué à -10.
Je ne comprends pas très bien les différentes réactions qu'il y a eu au post original "top chrono" : le gars était tout content de dire que ADSL ça rulez, avec chiffres à l'appui. J'en ai profité pour faire une petite comparaison avec ma liaison Renater, qui rulez encore mieux :)
Ces chiffres peuvent être intéressant en soi, c'est un petit instantanné du réseau qui va bien. Pourquoi nous opposer une histoire abracadabrante sur les citoyens du net qui partagent des ressources ? Qu'est-ce qu'on en a à cirer ? Si j'ai envie de gaspiller 27 M de bande passante, c'est mon droit, non ? Ah ces petits jeunes, faut tout leur expliquer. Tu as la moindre idée du trafic réseau d'une fac ? Quelques mégas, c'est absolument ridicule. Vas-y, cours éteindre ton moniteur, tu es en train de gaspiller 0,3 kwh.
[^] # Oh le joli beauf !
Posté par TSelek . Évalué à 4.
Maintenant, celui qui maintient un serveur ou un mirroir est surement atterré par de tels comportements. Combien se sont fait ejecter d'hebergeurs gratuits pour dépassement de bande ? Combien abandonnent lorsqu'il s'agit de payer la bande ?
En tant que contribuable qui paye in fine ta connectivité, je dis qu'il y des baffes qui se perdent à la fac.
[^] # Re: Oh le joli beauf !
Posté par Alexandre DATH (site web personnel) . Évalué à 1.
[^] # Re: top chrono !!
Posté par PLuG . Évalué à 5.
Chacun pour sa pomme et moi devant tout le monde.
Pourquoi trier ma poubelle, personnellement je jette si peu d'ordures par rapport au 60M de Français !!
Pourquoi je pourrai pas rouler sur la bande d'arret d'urgence au lieu de faire la queue connement ? c'est pas une bagnole qui va gener les secours !!
Et pourquoi je ferai la queue au supermarché, ils peuvent bien me laisser passer, c'est pas moi qui vais les mettre en retard ...
Tu sais quoi, kilucru, je suis bien content de ne pas te connaitre personnellement, je te reconnais malheureusement trop souvent dans la vie !!
[^] # Re: top chrono !!
Posté par Cru Kilu . Évalué à -4.
> This server sits on a 100 Mbit/s connection graciously provided by
> Globix Internet (http://www.globix.net/(...)), and uses hardware provided
> by VA Linux Systems (http://www.valinux.com/(...)).
C'est tout-à-fait un serveur qui va s'effondrer dés que on téléchargera 30 Mo, effectivement.
Bon, sans rire, quand vous, enfin je veux dire des amis à vous, téléchargez des MP3 de 3 à 5 Mo chacun, l'addition est très vite lourde pour un album ; quand vous regardez de la vidéo en streaming, vous ne savez même pas combien de Mo vous avez consommé, etc.
Ces deux exemples ne sont pas extrêmes, mais font une bonne part de la bande passante du grand public sur le net ; et l'infrastructure du net grandit en même temps. Ce qui était prohibitif hier est banal aujourd'hui et ridicule demain.
Oui bien sûr, sur un petit serveur ftp improvisé, ce genre de comportement est propre à écrouler le serveur en 2 temps 3 mouvements ; mais l'admin d'un tel serveur réfléchira à 2 fois avant de mettre des gros fichiers dessus ou de faire une pub mondiale, ou mettra en place un nombre limité de connexions simultannées.
Bref que du blabla pour ne rien dire, juste gueuler un peu contre 2 ou 3 moralisateurs, pr0ut sur eux !
(au fait, je fais sagement la queue au supermarché et je ne roule jamais sur la bande d'arrêt d'urgence, vas te faire épiller les soeur Bronté avec une pince à linge)
[^] # Re: top chrono !!
Posté par PLuG . Évalué à 2.
Si tu as déjà l'album en question, te viendrait-il à l'idée de le télécharger en MP3 ? même une seule chanson ??
Pourtant tu télécharge bien 90% de kernel que tu as déjà !!
Bref c'est pas parce que les ressources sont nombreuses qu'il faut les gaspiller. Et le plus embetant, c'est pas que de la BP soit gaspillée, c'est qu'elle le soit VOLONTAIREMENT. Entre un neu² qui télécharge pour rien et un type qui fait l'apologie du gaspillage d'octet, il y a une nuance. Pour un des 2 on ne peut plus rien faire !!
[^] # Re: top chrono !!
Posté par Cru Kilu . Évalué à -2.
Ensuite, je n'ai pas de kernel 2.4.x, donc je ne télécharge pas ce que j'ai déjà.
Bon, si je voulais vraiment économiser de la bande passante, je passerai par un proxy, c'est vrai ;
L'apologie du gaspillage d'octets ? Relis mes posts, nulle part je ne fais l'apologie de quoi que ce soit. Je dis qu'il faut être réaliste et se ramener aux ordres de grandeur actuels.
Gaspiller de la BP .. quand je vais sur un site web qui commence à ramer parce qu'il m'envoie des tonnes de gifs animées de pub, des flash de 300K dont je n'ai que faire, etc, là oui, de la BP est gaspillée. Quand je télécharge un tar.gz sur un serveur ftp musclé qui a une très grosse liaison sur internet, que ce serveur est aux USA et que je télécharge le matin, c'est-à-dire quand les USA dorment, non, désolé, je ne gaspille rien, je ne fais qu'utiliser une infrastructure largement disponible ; si ça avait ramé, j'aurais de suite interrompu, en vrai _citoyen du net_.
Aussi, j'insiste, pourquoi tant de morale ? Et pourquoi avoir descendu le type du premier post sur "ADSL rulez" ?
En plus, des exemples de vrais gaspillages, moi j'en vois, et des vrais : des mecs qui recommencent pour la 15ème fois la copie du CD complet du dernier macOSX, because la ftp qui foirent en plein milieu, et qu'ils ne connaissent ni le reget de ftp, ni wget qui le fait tout seul, bref : plusieurs gigas au total. Ça c'est du gaspillage.
[^] # Codeur MP3 (Re: top chrono !!)
Posté par Olivier Jeannet . Évalué à 1.
Je suis un peu hors-sujet mais d'une part on ne dit pas encodeur mais codeur (codec = codeur/décodeur), et d'autre part il y a l'excellent LAME qui fonctionne très bien, c'est celui que j'utilise (il fonctionne également sous Windows et a des frontaux graphiques). Tape "LAME" ou "NotLAME" dans google et tu devrais trouver la page d'accueil. BladeEnc est moins bon d'après mes expériences d'il y a plusieurs mois.
[^] # Re: top chrono !!
Posté par poil oq . Évalué à 6.
devant mon écran
j'ai cru bien longtemps
ne rien gaspiller
lorsque je surfais
comme je suis content
j'écris mon bonheur
mais de temps en temps
on'm'traite de voleur
et là kilucru
défend poiloq
pour mettre en avant
les téléchargements
(ADSL rulez !!) oh les beaux (.Y.) !!
[^] # Re: top chrono !!
Posté par Anonyme . Évalué à -1.
Allez tous votez [-] pour kilucru !
# Ce qui change chez moi
Posté par Olivier . Évalué à 6.
Maintenant, avec le nouveau driver totalement réécrit, plus besoin de s'encombrer avec des bidouillages : tout fonctionne comme une carte réseau normale !
(A noter aussi une amélioration de la carte ESS Solo sur mon Thinkpad : avant il n'y avait pas moyens, j'étais obligé d'utiliser Alsa... maintenant, sur le Thinkpad 390X, aucuns problèmes avec l'ESS Solo1)
Sinon au niveau de la gestion de mémoire, ça me semble mieux mais j'ai pas d'éléments objectifs là dessus...
[^] # Re: Ce qui change chez moi
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
bref, mon /var/lib/pcmcia/stab ne se remplit pas correctement (sauf si je prends un pcmcia < 3.1.26)
et les scripts /etc/pcmcia/network|shared ont l'air de chier....
[^] # Re: Ce qui change chez moi
Posté par Anonyme . Évalué à 0.
Je sais pas si ça marchait avant le 2.4.9 (j'avais jamais essayé avant), mais en tout cas, ça marche nickel sur le 2.4.10 :)
Par contre, j'ai toujours des débits de merde en synchro avec mon PDA par infrarouge :( (mais c'est pas dit que ça vienne du noyau)
# ENFIN, C'EST PAS TROP TOT !
Posté par Anonyme . Évalué à -1.
Les drivers sont reecrits, possibilité d'utiliser la Webcam Philips, et en plus une gestion memoire améliorée, plus de clavier qui se bloque !
Franchement, je conseil aux Experts de telecharger et compiler le noyau, aux nouveaux d'attendre la prochaine distrib incluant ce noyau !
[^] # Re: ENFIN, C'EST PAS TROP TOT !
Posté par Anonyme . Évalué à 4.
1. Le 2.4.4 était le pire de tous en ce qui concerne la VM, et aussi pour certains drivers comme les RTL8139
Ca a commencé à s'améliorer avec le 2.4.6 et depuis c'est de mieux en mieux.
2. Il n'est pas nécessaire d'être un expert pour compiler un noyau.
Je n'en suis pas un, et ça fait un bon bout de temps que je sais comment compiler un noyau avec les bonnes options.
[^] # Re: ENFIN, C'EST PAS TROP TOT !
Posté par Anonyme . Évalué à -1.
...*Aïe* !
(Zou, -1 & Anonyme pour faire baisser ses XP).
# Re: Des infos précises
Posté par Julien Portalier . Évalué à 0.
Je me demande aussi pourquoi LT ne l'intègre pas au kernel non plus ...
[^] # Re: Des infos précises
Posté par Ray Mond . Évalué à 0.
tu fais comment en 2 minutes, non parce-que si c'est si rapide, moi je prends de suite!
(déjà qu'après avoir lu tout cela je suis bien tenté de retrouver un 2.4.x que j'avais quitté justement à cause de la lenteur qu'il imposait à ma machine)
Et sinon, ca marche bien le ext3 (pas que je m'y mette si c la galère...
--
O XP! pfouh... même au carré ça fait toujours 0 !
[^] # Re: Des infos précises
Posté par Julien Portalier . Évalué à 1.
$ tune2fs -j /dev/hdxx
ça crée le fichier journal, et il ne reste plus qu'à remonter la partition en ext3, et non pas en ext2, et le tour est joué !
Ensuite à l'utilisation, je n'ai eu aucun problème, bien au contraire ! Et merde une coupure de courant, pas grave, je n'ai perdu aucune donnée ! Sinon quand à savoir si c'est + rapide ou + lent, à l'utilisation je ne sens pas de différence notable, il faudrait faire des tests.
[^] # Re: Des infos précises
Posté par Vivi (site web personnel) . Évalué à 0.
peut-être à cause de ça :
«The Linux Coda drivers and the ext3 patches don't seem to get along very well, ...»
vu sur kernel traffic : http://kt.zork.net/kernel-traffic/latest.html#6(...)
[^] # Re: Des infos précises
Posté par Corsaire . Évalué à 1.
"Le bouton rouge s'appuie toujours plus vite... "
# Memory
Posté par asyoo asyoo . Évalué à -1.
facon qu' une mémoire de marque ex : mushkin en tenant compte du cas 2.2.2
Il y a surement une influence a ce niveau là.
[^] # Re: Memory
Posté par dguihal . Évalué à 4.
[^] # Re: Memory
Posté par Anonyme . Évalué à -2.
# jcomprends pas moi ca swap pas !?
Posté par B. franck . Évalué à -4.
[frbn@f00 frbn]$ free
_____________total_______used_______free_____shared____buffers_____cached____kevin
Mem:________2097152____1187432___909720_____112_____21676______34232____1
-/+ buffers/cache: 31524 63088
Swap:_______3066868______0_________3066868
[frbn@f00 frbn]$ uname -a
Linux f00 4.8.10 #1 Sat Jun 16 08:08:07 EDT 2011 i986 -alpha
ps: pardon c'est la fin de journée...
[^] # Re: jcomprends pas moi ca swap pas !?
Posté par Schneider Dark . Évalué à -1.
# vm = 1, apm = 0
Posté par Anonyme . Évalué à -1.
avec le 2.4.9, apm -s fonctionnait bien :(
# il est bien mieux...
Posté par Olivier Faurax (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.