URL: https://linuxfr.org/users/farib/journaux/gestion-du-swap-par-linux-si-efficace-que-cela Title: Gestion du swap par Linux : si efficace que cela ? Authors: farib Date: 2004年02月17日T12:40:17+01:00 Tags: Score: 0 Bon, l'utilisation que j'ai faite de certains logiciels est sans doute très particulière, mais le comportement de ma machine m'a quelque peu déçu. Il existe une communauté géniale ([http://www.ldraw.org(...)](http://www.ldraw.org)), des outils performants ([http://URL_SUPPRIMEE/mlcad.png(...)](http://URL_SUPPRIMEE/mlcad.png) , tournant parfaitement sous Wine) qui permettent de construire des LEGO (TM) (R) pour obtenir avec le raytracer Pov-Ray des résultats assez agréables à l'oeil, comme [http://URL_SUPPRIMEE/ph34r.png(...)](http://URL_SUPPRIMEE/ph34r.png) (un vilain star destroyer impérialiste). Seulement, ça, c'est le gros modèle à 300$ qui contient 3000 pièces. Les différents outils génèrent un fichier source pov, c'est à dire un script décrivant en primitives du langage pov la bête. Le problème, c'est que ce fichier est énorme (1Mo), et son parsage par le moteur de Pov-Ray consomme _énormément_ de ressources mémoire. En effet, même une petite brique de base, est décrite en langage pov-ray de manière extrèmement précise. La mise en graphe du script pour en faire des objets mémoire propres au moteur est _gourmande_ Le rendu proprement dit prend le temps qu'il faut, mais s'effectue à une charge de mémoire de 400Mo _relativement_ faible. Seulement, sous GNU/Linux, lors du parsage, avec 3Go (sissi) de swap et 512 Mo de Ram, c'est grimpé péniblement jusqu'à me laisser 150 Mo de swap libre, ça a oscillé péniblement autour de cette valeur pendant quelques minutes, puis Pov-Ray a lamentablement planté par manque de mémoire. Tandis que sous cette immondice de zinzinXP, la charge totale en mémoire est montée tranquillement jusqu'à 1.5 Go (swap+ram) "seulement", est restée une quinzaine de secondes à ce niveau, pour redescendre linéairement jusqu'aux 400Mo nécessaires au rendu. Dans les deux cas, on a le même moteur de rendu, natif sur la plateforme, mais j'avoue peiner à accepter que sous GNU/Linux ça ait misérablement planté, alors que sous l'OS paslibre kipuduku (qui gère même le swap avec un fichier et non une partition), ce soit passé. Pourtant, j'imagine mal comment deux algorithmes de gestion du swap pourraient être si différents. J'ai vraiment du tomber sur le pire cas de l'algo de mon noyau adoré.