Performances de lecture() et d'écriture() vers/depuis des SKB Linux

Question

Basé sur un système Linux standard, où il y a une application utilisateur et la pile réseau du noyau. J'ai lu que le déplacement de trames de l'espace utilisateur vers l'espace noyau (et vica-versa) peut être coûteux en termes de cycles CPU.

Mes questions sont les suivantes,

1. Pourquoi ? Le déplacement de la trame dans un sens (c'est-à-dire de l'utilisateur vers le noyau) a un impact plus important. noyau) a un impact plus important.
2. En outre, comment les choses diffèrent-elles lorsque vous lorsque vous passez à des interfaces basées sur TAP. Comme le cadre sera toujours en cours entre l'espace utilisateur et l'espace noyau. Les problèmes d'espace s'appliquent-ils, ou y a-t-il une forme de copie zéro en jeu ?

Answer 1

Répondre aux questions en ligne :

---

Pourquoi ? Le déplacement de la trame dans un sens (c'est-à-dire de l'utilisateur vers le noyau) a un impact plus important. noyau) a un impact plus important.

Le déplacement vers/depuis les espaces utilisateur/noyau est coûteux. parce que le système d'exploitation doit le faire :

• Valider les pointeurs pour l'opération de copie.
• Transférer les données réelles.
• Assumer les coûts habituels liés à la transition entre le mode utilisateur et le mode noyau.

Il y a quelques exceptions à cette règle, par exemple si votre pilote implémente une fonction stratégie telle que le "saut de page". qui remappe effectivement un morceau/une page de mémoire pour qu'il/elle soit accessible à une application en espace utilisateur. Cette opération est "suffisamment proche" d'une opération de copie zéro.

En ce qui concerne copy_to_user / copy_from_user les performances des deux fonctions sont apparemment comparables.

---

De même, comment les choses diffèrent-elles lorsque l'on passe à des interfaces basées sur le TAP. Comme la trame passera toujours entre l'espace utilisateur et l'espace noyau. Est-ce que les problèmes d'espace d'espace s'appliquent-elles, ou y a-t-il une forme de copie zéro en jeu ?

Avec les interfaces basées sur TUN/TAP, les mêmes considérations s'appliquent, à moins que vous n'utilisiez une sorte de logique DMA, de retournement de page, etc.

Answer 2

Changement de contexte

Le déplacement des trames de l'espace utilisateur vers l'espace noyau est appelé changement de contexte, qui est généralement provoqué par un appel système (qui invoque la fonction int 0x80 interrompre).

• L'interruption se produit, entrant dans l'espace du noyau ;
• Lorsqu'une interruption se produit, os stocke la valeur de tous les registres dans le fichier pile noyau d'un fil : ds , es , fs , eax , cr3 etc.
• Ensuite, il saute au gestionnaire d'IRQ comme un appel de fonction ;
• Par le biais d'un chemin d'exécution commun d'IRQ, il choisira le prochain thread à exécuter par un certain algorithme ;
• Les informations d'exécution (tous les registres) sont chargées à partir du thread suivant ;
• Retour à l'espace utilisateur ;

Comme nous pouvons le voir, nous allons faire beaucoup de travail lors du déplacement de la trame dans/hors du noyau, ce qui est beaucoup plus de travail qu'un simple appel de fonction (juste la mise en place de ebp , esp , eip ). C'est pourquoi ce comportement est relativement long.

Dispositifs virtuels

En tant que périphérique de réseau virtuel, l'écriture sur TAP ne présente aucune différence par rapport à l'écriture sur un périphérique de réseau virtuel. /dev/xxx .

Si vous écrivez sur TAP, os sera interrompu comme dans la description ci-dessus, puis il copiera vos arguments dans le noyau et bloquera votre thread actuel (en bloquant IO). Le thread du pilote du noyau sera notifié d'une manière ou d'une autre (par exemple par une file de messages) pour recevoir les arguments et les consommer.

Dans Andorid, il existe un certain Appel système sans copie Dans mes implémentations de démonstration, cela peut être fait par la traduction d'adresse entre l'utilisateur et le noyau. Comme le noyau et le thread utilisateur ne partagent pas le même espace d'adressage et que les données du thread utilisateur peuvent être modifiées, nous copions généralement les données dans le noyau. Donc, si nous remplissons les conditions, nous pouvons éviter la copie :

• cet appel système doit être bloqué, c'est-à-dire que les données ne seront pas modifiées ;
• traduire entre les adresses par des tables de pages, c'est-à-dire que le noyau peut se référer aux bonnes données ;

Code

Les codes suivants proviennent de ma démo os, qui est liée à cette question si vous êtes intéressé par le détail :

• procédure de traitement des interruptions : do_irq.S , irq_handle.c
• appel système : syscall.c , ide.c
• la traduction d'adresses : MM_util.c