Dans certaines applications intensives en calcul aussi, ça peut faire la différence. Du point de vue performances, s'il est possible de modifier les algos de calcul (analyse numérique en général, traitement d'image ou de signal, etc.) de façon à ce que des blocs de données soient utilisés le plus longtemps possible dans les caches, on va gagner en perf (vu que la mémoire cache est plus rapide que la RAM). Mais si à cause d'une trop grande fragmentation mémoire je me retrouve avec de la mémoire non-contiguë, ça finit par faire désordre [1].
Théoriquement, l'utilisation des « superpages » (ou « huge pages ») permet justement d'éviter des défauts de TLB, d'améliorer la façon dont les données sont mappées dans les sets des caches, etc., mais sous Linux, et particulièrement avec du x86 en tout cas, leur utilisation est plutôt difficile : sous x86 et x86-64 par exemple, les huge pages font 2 ou 4 Mio, ce qui est trop pour beaucoup d'applications. Mais si ce n'était que ça encore, ça irait. Le problème vient aussi du fait que pour utiliser ces grosses pages, il faut en gros les allouer au boot de la machine, juste au moment de l'init de Linux, qui va réserver ces pages au démarrage. La mémoire ainsi réservée est perdue pour les autres programmes. Et si j'avais besoin d'une grosse page de plus, ben tant pis (si je me souviens bien, la HugePageTLB des archis x86 est de 4 entrées, de toute manière ...).
Pour le coup, il y a un problème inhérent à l'archi actuelle des x86/x86_64, car une page physique fait obligatoirement 4kio. Sur d'autres architectures (Alpha, Itanium par ex), il existe plusieurs tailles possibles pour les pages mémoire, ce qui permet de limiter la fragmentation de la mémoire en fonction de l'utilisation faite de la machine [2].
[1] Ne pas me demander pourquoi, je suis encore en train d'essayer de piger. Pour simplifier, si je lance une appli de calcul intensif au boot d'une machine je vais avoir un certain temps d'exécution. Si je la relance après plusieurs heures, où entre temps j'ai joué avec Eclipse, Firefox, que sais-je (n'importe quoi qui fragmente bien la mémoire), si ensuite je lance mon appli de calcul qui fait un bon gros malloc/mmap au début, la mémoire réellement allouée va être fragmentée tout partout, et il y a un impact direct sur la performance.
[2] Bon OK, en pratique ça veut juste dire qu'on a des blocs de mémoire contiguë plus gros (par exemple sur Itanium 2, je crois que les distribs Red Hat ont mis 64kio par défaut pour une page normale, et 256 Mio pour une huge page). En même temps, quand on a dans les 1 à 4Gio de RAM comme c'est de plus en plus fréquent, on peut se permettre d'avoir des tailles de pages plus grosses ! Surtout si une grande partie de celle-ci sert de cache disque : ça n'enlèvera a priori rien aux perfs. Au contraire.
[^] # Re: Juste une question
Posté par lasher . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 7.
Théoriquement, l'utilisation des « superpages » (ou « huge pages ») permet justement d'éviter des défauts de TLB, d'améliorer la façon dont les données sont mappées dans les sets des caches, etc., mais sous Linux, et particulièrement avec du x86 en tout cas, leur utilisation est plutôt difficile : sous x86 et x86-64 par exemple, les huge pages font 2 ou 4 Mio, ce qui est trop pour beaucoup d'applications. Mais si ce n'était que ça encore, ça irait. Le problème vient aussi du fait que pour utiliser ces grosses pages, il faut en gros les allouer au boot de la machine, juste au moment de l'init de Linux, qui va réserver ces pages au démarrage. La mémoire ainsi réservée est perdue pour les autres programmes. Et si j'avais besoin d'une grosse page de plus, ben tant pis (si je me souviens bien, la HugePageTLB des archis x86 est de 4 entrées, de toute manière ...).
Pour le coup, il y a un problème inhérent à l'archi actuelle des x86/x86_64, car une page physique fait obligatoirement 4kio. Sur d'autres architectures (Alpha, Itanium par ex), il existe plusieurs tailles possibles pour les pages mémoire, ce qui permet de limiter la fragmentation de la mémoire en fonction de l'utilisation faite de la machine [2].
[1] Ne pas me demander pourquoi, je suis encore en train d'essayer de piger. Pour simplifier, si je lance une appli de calcul intensif au boot d'une machine je vais avoir un certain temps d'exécution. Si je la relance après plusieurs heures, où entre temps j'ai joué avec Eclipse, Firefox, que sais-je (n'importe quoi qui fragmente bien la mémoire), si ensuite je lance mon appli de calcul qui fait un bon gros malloc/mmap au début, la mémoire réellement allouée va être fragmentée tout partout, et il y a un impact direct sur la performance.
[2] Bon OK, en pratique ça veut juste dire qu'on a des blocs de mémoire contiguë plus gros (par exemple sur Itanium 2, je crois que les distribs Red Hat ont mis 64kio par défaut pour une page normale, et 256 Mio pour une huge page). En même temps, quand on a dans les 1 à 4Gio de RAM comme c'est de plus en plus fréquent, on peut se permettre d'avoir des tailles de pages plus grosses ! Surtout si une grande partie de celle-ci sert de cache disque : ça n'enlèvera a priori rien aux perfs. Au contraire.