Gestion des interruptions à faible latence (délai avg attendu pour le retour du noyau vers l'espace utilisateur)?

Question

J'ai un lien fibre optique, avec un pilote de périphérique propriétaire.
Le lien entre dans une carte PCIe. En cours d'exécution sur un RHEL 5.2 (2.6.18-128 ~)
J'ai mmap 'l'interface sur la carte pour l'installation et l'accès FIFO etc, et ces lectures/écritures prennent quelques μs à compléter, donc tout y est bon.

Mais bien sûr, je ne peux pas l'utiliser pour les interruptions, donc je dois utiliser le module noyau fourni, avec son interface lib-espace utilisateur.

WaitForInterrupt(); // API lib interface to kernel module 
// Interrupt occurs and am returned to my code in user space 
time = CurrentTime() - LatchedTime(); // time to get to here 

Il faut environ 70μs pour revenir de WaitForInterrupt(). (L'heure à laquelle l'interruption est déclenchée est mémorisée dans le firmware, j'ai lu ceci, ce que je dis plus haut prend ~ 2μs, et comparez-le avec l'heure actuelle dans le firmware)

Quels sont les temps d'accès attendus entre une interruption et l'API de l'espace utilisateur interrompt la méthode d'attente d'appel?

Interfaces réseau/autres interfaces haute vitesse?

Answer 1

Si vous êtes en mesure de dépasser de manière fiable 500us sur un système qui n'est pas lourdement chargé, je pense que vous est en train de regarder une mauvaise implémentation de pilote (ou son wrapper/homologue d'espace utilisateur). Dans mon expérience, la latence pour réveiller un thread utilisateur sur l'interruption devrait être inférieure à 10us, bien que (comme d'autres l'ont dit) Linux ne fournit aucune garantie de latence.

Answer 2

500ms est beaucoup ordres de grandeur plus grandes que ce qu'un simple commutateur entre l'espace utilisateur/noyau prend, mais comme quelqu'un l'a mentionné dans les commentaires, linux n'est pas un système d'exploitation en temps réel, donc il n'y a pas de 500ms de garantie « de hickups » ne apparaître de temps en temps.

Il est tout à fait impossible de dire quel est le coupable, le pilote de périphérique pourrait simplement essayer de regrouper des données pour être plus efficace. Cela dit, nous avons eu des problèmes sans fin avec certaines cartes et interactions personnalisées avec APIC et ACPI, ce qui nécessite un équilibre délicat des paramètres du BIOS, quelle carte entre dans quel slot PCI et si une carte vidéo particulière détruit tout - probablement une cause d'un pilote douteux interagissant avec des bios/cartes vidéo plus ou moins boguées.

Answer 3

Si vous avez un noyau récent, vous pouvez utiliser l'outil perf sched pour mesurer la latence et voir où l'heure est utilisée . (500us sonne un peu sur le côté haut, en fonction de votre processeur, combien de tâches sont en cours, ...)