Qu'est-ce qui vous fait penser mremap pourrait jamais être efficace pour échanger des pages 4k uniques ? À tout le moins, un aller-retour vers l'espace noyau, même pour lire une seule valeur (comme pid) et la renvoyer, coûtera plus cher que de déplacer 4 ko de données. Et c'est avant d'en venir aux coûts d'invalidation du cache/TLB de remappage de la mémoire, que je ne comprends pas assez bien pour être abordés dans cette réponse, mais qui devraient avoir des coûts importants.
mremap est utile pour essentiellement une chose :implémenter realloc pour grand allocations desservies par mmap . Et en gros, je veux dire probablement au moins 100 000.
Il semble qu'il n'y ait pas de mécanisme utilisateur plus rapide pour réorganiser les pages mémoire que memcpy(). mremap() est beaucoup plus lent et n'est donc utile que pour redimensionner une zone de mémoire précédemment affectée à l'aide de mmap().
Mais les tableaux de pages doivent être extrêmement rapides, je vous entends dire ! Et il est possible pour l'espace utilisateur d'appeler des fonctions du noyau des millions de fois par seconde ! Les références suivantes aident à expliquer pourquoi mremap() est si lent :
"An Introduction to Intel Memory Management" est une belle introduction à la théorie du mappage de pages mémoire.
"Concepts clés de la mémoire virtuelle Intel" montre comment tout cela fonctionne plus en détail, au cas où vous envisagez d'écrire votre propre système d'exploitation :-)
"Partage des tables de pages dans le noyau Linux" montre certaines des décisions architecturales difficiles de mappage de pages mémoire Linux et leur effet sur les performances.
En regardant les trois références ensemble, nous pouvons voir qu'il y a eu peu d'efforts jusqu'à présent de la part des architectes du noyau pour exposer efficacement le mappage des pages mémoire à l'espace utilisateur. Même dans le noyau, la manipulation de la table des pages doit se faire en utilisant jusqu'à trois verrous ce qui sera lent.
À l'avenir, étant donné que la table de pages elle-même est composée de pages 4k, il peut être possible de modifier le noyau afin que des pages de table de pages particulières soient uniques à un thread particulier et puissent être supposées avoir un accès sans verrouillage pendant la durée du traiter. Cela faciliterait une manipulation très efficace de cette page de table de pages particulière via user-land. Mais cela sort du cadre de la question d'origine.