J'ai corrigé dans mon deuxième commentaire le fait que les small pages gardent un intérêt.
Pour ce qui est de la localité, c'est en effet très utile pour les codes parallèles mais ça l'est aussi pour tous les autres codes. Que tes accès soient optimisés ou pas, tu va augmenter la localité avec des pages plus grosses.
Il y a eu plusieurs article sur le fait que généralement des données allouées avec un faible intervalle de temps serons utilisées avec un très faible intervalle de temps. Plus tes pages sont grosses, plus tu as de chance que ces données soient dans la même page et donc proche en mémoire.
C'est sûr qu'optimiser réellement sont code pour la localité fait gagner mais le comportement de base de beaucoup de structures de données permet d'obtenir un minimum de localité si le reste est bien géré.
Et l'argument de la localité ne s'applique pas qu'au données comme tu le dis mais aussi au code, la majorité des compilateurs optimise même la position des fonctions dans le binaire afin que les fonctions qui s'appellent entre elles soient proches. Le cache de niveau 2 est partagé avec les données ce qui demande de la localité, le cache de niveau 1 est séparé mais demande aussi de la localité.
Ca fait des années que les hugepages existent et personne n'a demandé une telle config dans le noyau, il doit y avoir une raison... Peut-être parce qu'il y a des gens qui ont fait des vrais études et mesures et constaté que ca ne changeait pas grand chose aux perfs.
C'est surtout que ça fait des années qu'utiliser des hugepage est une galère monstrueuse et que donc les gens restent sur les petites...
Mais surtout je ne veux pas l'imposer à tout le monde mais avoir le choix.
[^] # Re: Transparent huge pages
Posté par beagf . En réponse à la dépêche Le noyau Linux est disponible en version 2.6.38. Évalué à 3.
J'ai corrigé dans mon deuxième commentaire le fait que les small pages gardent un intérêt.
Pour ce qui est de la localité, c'est en effet très utile pour les codes parallèles mais ça l'est aussi pour tous les autres codes. Que tes accès soient optimisés ou pas, tu va augmenter la localité avec des pages plus grosses. Il y a eu plusieurs article sur le fait que généralement des données allouées avec un faible intervalle de temps serons utilisées avec un très faible intervalle de temps. Plus tes pages sont grosses, plus tu as de chance que ces données soient dans la même page et donc proche en mémoire.
C'est sûr qu'optimiser réellement sont code pour la localité fait gagner mais le comportement de base de beaucoup de structures de données permet d'obtenir un minimum de localité si le reste est bien géré.
Et l'argument de la localité ne s'applique pas qu'au données comme tu le dis mais aussi au code, la majorité des compilateurs optimise même la position des fonctions dans le binaire afin que les fonctions qui s'appellent entre elles soient proches. Le cache de niveau 2 est partagé avec les données ce qui demande de la localité, le cache de niveau 1 est séparé mais demande aussi de la localité.
C'est surtout que ça fait des années qu'utiliser des hugepage est une galère monstrueuse et que donc les gens restent sur les petites...
Mais surtout je ne veux pas l'imposer à tout le monde mais avoir le choix.