Un flux peut traiter les complétions directement depuis lecture et écriture. Cela change la manière d’attendre les données, ainsi que le temps CPU potentiellement consommé.
Le code est présent dans la version candidate
Le commit USB4STREAM ajoute busy_poll aux attributs ConfigFS du flux. L’implémentation figure dans stream.c de Linux 7.3-rc2. Elle traite les complétions des anneaux depuis lecture et écriture plutôt que via leur chemin d’interruption.
En mode actif, le callback poll renvoie un masque d’erreur. Une lecture bloquante sans données scrute encore, vérifie les signaux et permet un réordonnancement. Une lecture non bloquante peut renvoyer EAGAIN. L’ancienne affirmation d’un cœur occupé en permanence dès qu’un flux existe était excessive.
Régler avant d’ouvrir le flux
La fonction d’écriture de busy_poll vérifie la présence d’utilisateurs du flux. Si celui-ci est ouvert, elle renvoie EBUSY au lieu de modifier le mode sous leurs pieds. Ce n’est donc pas un réglage de performance modifiable librement à tout instant.
Notre schéma compare trois cas où la file de réception est vide : attente bloquante ordinaire, lecture bloquante en mode busy et lecture non bloquante dans ce mode. Il montre un parcours d’exécution, pas une latence mesurée. Créer un flux sans appel de scrutation actif diffère d’un lecteur dédié tournant en boucle.
Mesurer latence et temps CPU ensemble
Pour l’évaluation, fixer taille des paquets, charge proposée, câble, matériel et placement du processus. Inclure période calme et rafales, pas seulement saturation. Relever distribution des latences et temps CPU sur le même intervalle. Une médiane meilleure avec de pires latences extrêmes ou un coût CPU excessif peut changer la décision.
Une application fondée sur la disponibilité des descripteurs doit prendre en compte le nouveau comportement de poll. Remplacer cette attente par des lectures répétées peut modifier annulation, équité entre flux et arrêt. Le noyau exécute toujours du code ; busy polling ne signifie ni contournement du noyau ni suppression de tout coût d’ordonnancement.
Aucun lien USB4 n’a été chronométré pour cet article. Le code établit une conclusion plus précise : ce mode propose un chemin alternatif avec des attentes explicites. Son intérêt exige des mesures de l’application concernée, pas une promesse générale déduite du mot « polling ».
Revue du 8 septembre : code 7.3-rc2 vérifié, occupation permanente d’un cœur corrigée ; comportement des appels et EBUSY précisés.