Si on a vraiment besoin de faire de grosses allocations, il faudrait AMHA utiliser des huge pages et ça ne se gère pas de la même manière.
Deux remarques générales :
Utiliser les huge pages ne change pas le fait que malloc rendra toujours une adresse valide sous Linux (allocation optimiste), et donc que la valeur de retour sera presque tout le temps inutile (mais pas à ignorer si tu veux que ton code soit portable — il existe d'autres systèmes qui allouent la mémoire avec une stratégie différente).
Les huge pages sont utiles pour éviter la fragmentation mémoire et réduire les TLB miss. C'est tout (et en fait c'est déjà énorme pour un code qui cherche la haute performance et qui est memory bound). Ça ne joue pas sur l'allocation en elle-même.
En ce qui concerne Linux en particulier, la façon dont les huge pages sont implémentées tiens du gros hack (on doit spécifier le nombre de grandes pages qu'on veut allouer au boot, pour s'assurer de la contiguïté de la mémoire physique), et c'est géré plus ou moins via les mêmes mécanismes que pour les segments de mémoire partagée (en tout cas c'était le cas il n'y a pas si longtemps).
Pendant sa thèse, Alan Cox avait publié un article très bien sur les « superpages » et comment les allouer. Il avait fait ses tests sur Alpha avec FreeBSD. L'idée est de découper la mémoire virtuelle en utilisant la taille maximale des pages du système (sur x64 : 4Mio). Si la charge de la machine et le « profil » des programmes qui tourne dessus requièrent des allocations plus petites, une superpage est ensuite redécoupée en utilisant la taille de page directement inférieure à celle courante. Les différentes pages sont affectées aux pools pour chaque taille. Évidemment, le système doit essayer de recycler au maximum les pages de taille inférieure, pour limiter la fragmentation de la mémoire virtuelle. De même, si un ensemble de « petites » pages sont contiguës en mémoire, le système doit essayer de les « upgrader » vers le pool des pages de taille supérieure. Ce genre de méthode est très pratique sur les machines qui ont des tailles de page configurables (il y avait un microcode sur Alpha qui permettait de le faire; sur Itanium la taille des pages est arbitraire et configurable aussi; etc.).
[^] # Re: Laissez malloc tranquille !
Posté par lasher . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Deux remarques générales :
En ce qui concerne Linux en particulier, la façon dont les huge pages sont implémentées tiens du gros hack (on doit spécifier le nombre de grandes pages qu'on veut allouer au boot, pour s'assurer de la contiguïté de la mémoire physique), et c'est géré plus ou moins via les mêmes mécanismes que pour les segments de mémoire partagée (en tout cas c'était le cas il n'y a pas si longtemps).
Pendant sa thèse, Alan Cox avait publié un article très bien sur les « superpages » et comment les allouer. Il avait fait ses tests sur Alpha avec FreeBSD. L'idée est de découper la mémoire virtuelle en utilisant la taille maximale des pages du système (sur x64 : 4Mio). Si la charge de la machine et le « profil » des programmes qui tourne dessus requièrent des allocations plus petites, une superpage est ensuite redécoupée en utilisant la taille de page directement inférieure à celle courante. Les différentes pages sont affectées aux pools pour chaque taille. Évidemment, le système doit essayer de recycler au maximum les pages de taille inférieure, pour limiter la fragmentation de la mémoire virtuelle. De même, si un ensemble de « petites » pages sont contiguës en mémoire, le système doit essayer de les « upgrader » vers le pool des pages de taille supérieure. Ce genre de méthode est très pratique sur les machines qui ont des tailles de page configurables (il y avait un microcode sur Alpha qui permettait de le faire; sur Itanium la taille des pages est arbitraire et configurable aussi; etc.).