Compresser la mémoire cache de Linux

• # Intéressant.

  Posté par G. R. (site web personnel) le 09 juin 2001 à 10:23. Évalué à 1.

  

  C'est encore en développement et non utilisable, mais ça à l'air très prometteur.
  
  C'est une bonne idée, pour tout ceux qui n'ont pas des GO de mémoire, et qui veulent utiliser Mozilla.
  
  Encore une fois, le travail ouvert et collectif est bien plus productif du point de vue de l'innovation que la simple concurrence commerciale.

  • [^] # Re: Intéressant.

    Posté par Anonyme le 09 juin 2001 à 10:53. Évalué à 0.

    

    Lorsque la memoire etait super chere, il y a dix ans, il y avait deja des utilitaires pour compresser les donnees dans la RAM. Ca s'appelait doublemem sur mac, je crois. Le probleme est la perte de performance.

    • [^] # Re: Intéressant.

      Posté par kadreg le 09 juin 2001 à 11:14. Évalué à 1.

      

      Sauf que là, il me semble que l'on ne compresse que les pages mémoires destinées à être swappées sur disque. Donc la perte de temps du à la compression/decompression est largement regagné (parceque ce qui est en mémoire se compresse habituellement bien, même avcec des algo simples) par le fait que la lecture/ecriture disque est plus courte.

      • [^] # Re: Intéressant.

        Posté par Troy McClure (site web personnel) le 09 juin 2001 à 12:37. Évalué à 1.

        

        oui je trouve que c'est vraiment un bonne idée -- typiquement, quand la machine se met q swapper comme une folle, le taux d'utilisation du proc tombe à ~0%, autant en profiter.

        • [^] # Re: Intéressant.

          Posté par Anonyme le 09 juin 2001 à 22:54. Évalué à 0.

          

          Même si on "unmask" l'IRQ ?
          (hdparm -u 1 /dev/hdaX)

          • [^] # hdparm -u, détails ?

            Posté par Beurt le 10 juin 2001 à 02:02. Évalué à 1.

            

            Le man de hdparm n'est pas bien explicite à mes yeux sur les avantages de cette option.
            Pourais-tu (toi ou un autre) nous expliquer quel est l'avantage réel de l'option -u de hdparm autrement dit d'"unmasquer" les autres IRQ durant l'accès au disk ?
            Et puis aussi quels sont les risques (d'après le man les dommages peuvent être important pour certains chipsets et les vieux kernels. Et les autres chipsets, et les nouveaux kernels?)?

            • [^] # Re: hdparm -u, détails ?

              Posté par Anonyme le 10 juin 2001 à 13:29. Évalué à 0.

              

              Je ne connais pas les avantages concrets de cette methode, mais c'est censé optimiser les le temps de réponse géréral du système lors des accès disque. Je vous conseille de vous reporter à la page man d'hdparm ( peut être trouvé à http://www.linux.com/develop/man/8/hdparm/(...) ) ainsi qu'a http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html(...) pour plus d'infos sur ce sujet. Sinon il y a aussi une ancienne news linuxfr ( http://linuxfr.org/2001/03/05/2586,0,1,0.html(...) ).

    • [^] # Re: Intéressant.

      Posté par Anonyme le 09 juin 2001 à 11:32. Évalué à 0.

      

      ca s'applait RamDoubler il me semble mais je crois que le but était égallement d'améliorer la gestion de la mémoire (sous MacOS pas X c'est pas le top).
      
      --
      Etienne

  • [^] # Re: Intéressant.

    Posté par Anonyme le 09 juin 2001 à 13:32. Évalué à 0.

    

    C'est une bonne idée, pour tout ceux qui n'ont pas des GO de mémoire, et qui veulent utiliser Mozilla.
    
    

    Je ne crois pas que ce soit le but ici. Il s'agit plutot de gagner du temps sur l'ecriture/lecture du swape.

    
    
    

    Ce qui est rigolo, c'est que l'efficacite dependra beaucoup des performances du CPU par rapport au disk. Donc pourquoi pas make menuconfig, make benchmark , make bzImage.

    • [^] # Intéressant, mais ...

      Posté par Anonyme le 09 juin 2001 à 14:29. Évalué à 1.

      

      c'est intéressant mais je pense que le problème, ou plutot la solution, n'est pas là.
      Le fait est que depuis le kernel 2.4.4 la VM n'a cesser de se degrader au niveau de la gestion du cache et du swap.
      
      Personnellement le dernier kernel "correct" de ce point de vue est le 2.4.3.
      Ce probleme de VM est connu, et fait un tabac sur la mailing list du kernel.
      Il semble que l'orientation de la VM dans les 2.4.4/2.4.5 soit plutot orienté vers une amelioration de "la bande passante" au niveau de la gestion memoire, au detriment de "l'interactivité" au niveau temps de reponse avec les applications.
      
      Ce type de comportement est plus adapté aux entreprise qui utiliserais Linux comme serveur. Mais beaucoup moins pour une utilisation je dirais classique pour nous, c.a.d. un ch'tit peut serveur et un ch'tit peut desktop
      
      Donc compressé les pages de cache, pourquoi pas, mais il semble etre reconnu que les dernieres VM ne sont pas "tip top" pour nous, alors quand on entend des gars qui disent : "ben oui ce type de comportement est plus performant pour les entreprise, et pis c'est normal puisque c'est elle qui me paye".
      
      Alors "Bienvenue dans le e-Biz-Linux ..." ?

      • [^] # Re: Intéressant, mais ...

        Posté par Anonyme le 11 juin 2001 à 11:36. Évalué à 0.

        

        Bin je pense qu'on vas bientot avoir une option ce compil du kernel du style OPTIMIZE_SWAP_FOR_SERVER, et puis tout le monde sera content ...
        C'est d'ailleur la une des forces du logiciel libre: l'alternative.

        • [^] # Re: Intéressant, mais ...

          Posté par Anonyme le 11 juin 2001 à 23:45. Évalué à -1.

          

          <troll> Oui, utiliser FreeBSD, c'est une alternative</troll>
          
          -1 ? Adjugé !

Suivre le flux des commentaires

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