Journal Gestion du swap par Linux : si efficace que cela ?

Posté par  .
Étiquettes : aucune
0
17
fév.
2004
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(...)), des outils performants (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(...) (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é.
  • # Re: Gestion du swap par Linux : si efficace que cela ?

    Posté par  (site web personnel) . Évalué à 0.

    Achète plein de ram et mets ton swap dans un ramdisk, ça ira plus vite ... /o\
  • # Re: Gestion du swap par Linux : si efficace que cela ?

    Posté par  (site web personnel) . Évalué à 3.

    alors que sous l'OS paslibre kipuduku (qui gère même le swap avec un fichier et non une partition)

    Linux aussi peut se servir de fichier(s) pour la swap.
  • # Re: Gestion du swap par Linux : si efficace que cela ?

    Posté par  . Évalué à 1.

    deux algorithmes de gestion du swap pourraient être si différents
    Les mecanismes d'allocation memoire et de gestion de swap entre linux et windows sont radicalement different. Il s'agit de deux philosophie separee. Maintenant pour avoir plus de detail je laisse la place aux experts.
  • # Re: Gestion du swap par Linux : si efficace que cela ?

    Posté par  . Évalué à 2.

    Tu pourrais peut-être donner ta version du noyau, tes paramètres de gestion du disque dur, etc... ? Si tu veux qu'on t'aide à résoudre ton problème, il faut nous donner les moyens de le diagnostiquer ;-)
  • # Re: Gestion du swap par Linux : si efficace que cela ?

    Posté par  . Évalué à 3.

    Le problème n'a pas l'air de provenir de Linux :
    Pov-Ray a planté parce qu'il n'avait plus de mémoire disponible, ce qui est plutôt normal.
    Sous Windows, Pov-Ray planterait aussi s'il n'avait plus de mémoire (et peut-être le système entier aussi, mais je médis ;-)

    Donc, le problème vient de Pov-Ray, puisqu'il a l'air de consommer au moins deux fois plus de mémoire sous Linux que sous Windows. Peut-être qu'en recompilant avec les bonnes options la mémoire sera mieux gérée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.