web-dev-qa-db-fra.com

Pourquoi mmap () est plus rapide que les E / S séquentielles?

Duplicata possible:
mmap () vs. blocs de lecture

J'ai entendu (lire quelque part sur Internet) que mmap() est plus rapide que les E/S séquentielles. Est-ce correct? Si oui, alors pourquoi est-ce plus rapide?

  • mmap() ne lit pas de manière séquentielle.
  • mmap() doit aller chercher sur le disque lui-même comme read() le fait
  • La zone mappée n'est pas séquentielle - donc pas de DMA (?).

Donc mmap() devrait en fait être plus lent que read() à partir d'un fichier? Lesquelles de mes hypothèses ci-dessus sont fausses?

41
Lunar Mushrooms

J'ai entendu (lire quelque part sur Internet) que mmap () est plus rapide que les E/S séquentielles. Est-ce correct? Si oui, alors pourquoi est-ce plus rapide?

Cela peut être - il y a des avantages et des inconvénients, énumérés ci-dessous. Lorsque vous avez vraiment des raisons de vous soucier, toujours comparer les deux.

Indépendamment de l'efficacité réelle IO, il y a des implications sur la façon dont le code d'application suit quand il doit faire les E/S et fait le traitement/génération de données, ce qui peut parfois avoir un impact assez important sur les performances dramatiquement.

1) mmap () ne lit pas de manière séquentielle. 2) mmap () doit être récupéré sur le disque lui-même comme read () le fait 3) La zone mappée n'est pas séquentielle - donc pas de DMA (?).

Donc mmap () devrait être plus lent que read () depuis un fichier? Lesquelles de mes hypothèses ci-dessus sont fausses?

1) est faux ... mmap() assigne une région d'espace d'adressage virtuel correspondant au contenu du fichier ... chaque fois qu'une page de cet espace d'adressage est accessible, physique RAM is trouvé pour sauvegarder les adresses virtuelles et le contenu du disque correspondant est défectueux dans cette RAM. Ainsi, l'ordre dans lequel les lectures sont effectuées à partir du disque correspond à l'ordre d'accès. Il s'agit d'un mécanisme d'E/S "paresseux". Si, par exemple, vous deviez indexer dans une énorme table de hachage qui devait être lue à partir du disque, puis mmaping le fichier et commencer à faire l'accès signifie que les E/S du disque ne se font pas séquentiellement et peuvent donc entraîner un temps écoulé plus long jusqu'à ce que le fichier entier est lu en mémoire, mais pendant ce temps, les recherches réussissent et un travail dépendant peut être entrepris, et si des parties du fichier ne sont jamais réellement nécessaires, elles ne sont pas lues (autorisez la granularité des pages disque et mémoire, et que même lorsque vous utilisez le mappage de la mémoire, de nombreux systèmes d'exploitation vous permettent de spécifier quelques conseils d'amélioration des performances/d'efficacité de la mémoire ab vos schémas d'accès prévus afin qu'ils puissent lire de manière proactive à l'avance ou libérer de la mémoire de manière plus agressive sachant qu'il est peu probable que vous y retourniez).

2) absolument vrai

3) "La zone cartographiée n'est pas séquentielle" est vague. Les régions mappées en mémoire sont "contiguës" (séquentielles) dans l'espace d'adressage virtuel. Nous avons expliqué que les E/S disque étaient séquentielles ci-dessus. Ou pensez-vous à autre chose? Quoi qu'il en soit, alors que les pages sont en panne, elles peuvent en effet être transférées à l'aide de DMA.

De plus, il existe d'autres raisons pour lesquelles le mappage de la mémoire peut surpasser les E/S habituelles:

  • il y a moins de copie:
    • souvent, les routines au niveau du système d'exploitation et de la bibliothèque transmettent les données via un ou plusieurs tampons avant qu'elles n'atteignent un tampon spécifié par l'application, l'application alloue ensuite dynamiquement le stockage, puis copie du tampon d'E/S vers ce stockage afin que les données soient utilisables après la lecture du fichier.
    • le mappage de la mémoire permet (mais ne force pas) l'utilisation sur place (vous pouvez simplement enregistrer un pointeur et éventuellement une longueur)
      • continuer à accéder aux données en place risque d'augmenter l'échange plus tard: le fichier/la carte mémoire pourrait être plus détaillé que les structures de données dans lesquelles il pourrait être analysé, de sorte que les modèles d'accès aux données qu'ils contiennent pourraient avoir plus de retards de défaillance dans davantage de pages de mémoire
  • le mappage de la mémoire peut simplifier le travail d'analyse de l'application en laissant l'application traiter l'intégralité du contenu du fichier comme accessible, plutôt que de se demander quand lire un autre tampon plein
  • l'application diffère davantage de la sagesse du système d'exploitation concernant le nombre de pages physiques RAM à tout moment, partageant efficacement un cache de disque à accès direct avec l'application
  • comme le souhaitent les commentaires ci-dessous, "en utilisant le mappage de la mémoire, vous utilisez généralement moins d'appels système"
  • si plusieurs processus accèdent au même fichier, ils devraient pouvoir partager les pages de support physiques

Ce sont aussi des raisons pour lesquelles mmap peut être plus lent - lisez --- de Linus Torvald post ici qui dit de mmap:

... les jeux de table de page avec la surcharge (et même juste TLB manquant) sont facilement plus élevés que le coût de copie d'une page d'une manière agréable en streaming ...

Et d'un autre de ses messages :

  • coûts d'installation et de démontage assez notables. Et je veux dire perceptible. Ce sont des choses comme suivre les tableaux de pages pour tout démapper proprement. C'est la comptabilité pour maintenir une liste de tous les mappages. C'est le flush TLB nécessaire après avoir démappé des trucs.

  • le défaut de page coûte cher. C'est ainsi que le mappage est rempli, et c'est assez lent.

FWIW, la dernière fois que cela s'est produit pour moi au travail, l'entrée mappée en mémoire était 80% plus rapide que fread et al pour lire les enregistrements de base de données binaires dans une base de données propriétaire, sur Linux 64 bits avec ~ 170 Go de fichiers.

58
Tony Delroy
  1. mmap() peut partager entre les processus.
  2. Le DMA sera utilisé dans la mesure du possible. DMA ne nécessite pas de mémoire contiguë - de nombreuses cartes haut de gamme prennent en charge le DMA à diffusion groupée.
  3. La zone mémoire peut être partagée avec le cache de bloc du noyau si possible. Il y a donc copie du bailleur.
  4. La mémoire pour mmap est allouée par le noyau, elle est toujours alignée.
10
J-16 SDiZ

"Plus rapide" en termes absolus n'existe pas. Vous devez spécifier des contraintes et des circonstances.

mmap () ne lit pas de manière séquentielle.

qu'est ce qui te fait penser ça? Si vous accédez réellement séquentiellement à la mémoire mappée, le système récupère généralement les pages dans cet ordre.

mmap () doit extraire du disque lui-même de la même façon que read ()

bien sûr, mais le système d'exploitation détermine le temps et la taille du tampon

La zone mappée n'est pas séquentielle - donc pas de DMA (?).

voir au dessus

Ce que mmap aide, c'est qu'il n'y a pas de tampon d'espace utilisateur supplémentaire impliqué, la "lecture" a lieu là où le noyau du système d'exploitation le juge opportun et en segments qui peuvent être optimisés. Ceci peut être un avantage en termes de vitesse, mais tout d'abord ce n'est qu'une interface plus facile à utiliser.

Si vous voulez connaître la vitesse d'une configuration particulière (matériel, système d'exploitation, modèle d'utilisation), vous devez mesurer.

6
Jens Gustedt