Notes de version de HFTKernel 7.3.x.

Progression rapide après les barrières drain de io_uring

Une requête drain autonome efface désormais l'état drain lorsque sa completion est soumise à un flush et qu'aucun autre travail différé ne reste en attente. Pour l'exécution io-wq, cette transition a lieu sous le ring lock avant que la completion ne devienne visible en userspace.

Les requêtes soumises après l'achèvement de la barrière peuvent progresser sans attendre que le worker libère sa dernière référence à la requête. Les requêtes drain liées conservent leurs exigences d'ordonnancement.

Cela rend les pipelines I/O pilotés par les completions plus prévisibles pour les applications utilisant des barrières drain.

Wakeups poll fiables et completion multishot

Une opération atomique compare-and-exchange coordonne désormais la libération de l'ownership de poll avec les notifications de retry concurrentes. Les wakeups en attente restent visibles, permettant au traitement de continuer sans dépendre d'un événement sans rapport.

Le poll multishot met également à jour correctement le compteur de références partagé lors d'un hangup. Le dernier passage de traitement des événements peut s'achever sans boucles répétées inutiles, ce qui améliore la gestion du cycle de vie des connexions dans les applications asynchrones.

Timeouts précis de la completion queue sur PREEMPT_RT

Pour les tâches RT et deadline sur PREEMPT_RT, les callbacks de timeout de la completion queue de io_uring s'exécutent en contexte hard-interrupt. La transmission des wakeups ne dépend plus du scheduling du timer thread de priorité inférieure.

Dans le test amont sur Jetson Orin Nano, avec la modification appliquée par backport à Linux 6.18.39-rt, le retard maximal est passé de 1,040 µs à 18 µs sur 40,000 deadlines sous une charge SCHED_FIFO concurrente. Après la modification, tous les wakeups sont restés dans une limite de 100 µs de retard.

Traitement cohérent des grands provided buffers de réception

Pour les opérations de réception non-bundled dont la longueur provient d'un provided buffer, io_uring limite la longueur de transfert sélectionnée à MAX_RW_COUNT.

Cela maintient la validité de la longueur dans le chemin de retour utilisant une valeur signée, y compris pour les provided buffers de 2 GiB ou plus, tout en respectant la limite existante de taille de transfert. Cela renforce le traitement des buffers de réception pour les applications utilisant de grandes régions réutilisables.

Arrêt mieux coordonné des workers asynchrones

Le chemin de sortie de io-wq applique une memory barrier après la publication de son indicateur de sortie. L'arrêt et le task work concurrent de création des workers respectent l'ordre requis, y compris sur les architectures à modèle mémoire faiblement ordonné.

Cela renforce le teardown ordonné et le redémarrage des services utilisant des worker pools io_uring.

L'annulation des requêtes IORING_OP_WAITID est également idempotente : les tentatives répétées reconnaissent l'état d'annulation existant sans accumuler de références supplémentaires. Cela maintient la cohérence des requêtes asynchrones de supervision des processus pendant l'annulation.

Moins de travail inutile lors du teardown des PID namespaces

Pendant le nettoyage du namespace, le process reaper masque les wakeups des notifications task-work en attendant la fin des processus enfants et la libération des PID.

Il peut rester en sommeil jusqu'à l'événement pertinent du cycle de vie, au lieu de réintégrer à répétition son chemin d'attente. Cela réduit l'activité CPU évitable dans les interactions concernées entre l'arrêt des conteneurs et livepatch.

Visibilité fiable des IRQ par CPU sur les grands hôtes

/proc/interrupts émet désormais son en-tête CPU à chaque rendu du premier enregistrement, y compris lors des nouvelles tentatives après l'agrandissement du sequence buffer.

La correspondance entre CPU et compteurs reste intacte sur les systèmes comportant de nombreux cœurs. Cela permet un parsing fiable des IRQ, la vérification du placement et la surveillance des CPU isolés et de housekeeping.

Configuration et teardown du tracing plus propres

La configuration des histogrammes supprime désormais les triggers field-variable créés automatiquement lorsque la commande globale échoue. Le tracing actif correspond à la configuration acceptée, et l'instrumentation temporaire est nettoyée au lieu de continuer à compter les événements.

Le nettoyage des histogrammes field-variable conserve la référence stable à l'event-file au lieu de dépendre de la durée de vie d'un autre histogramme. Cela améliore la création, la modification et la suppression répétées des sessions de diagnostic.

Le parsing des event-filters rejette également les expressions logiques incomplètes avant leur exécution. Cela renforce la configuration automatisée de tracefs et des tracepoints perf.

Diagnostics postmortem plus complets

La collecte des core dumps est protégée contre les interruptions TIF_NOTIFY_SIGNAL lors du transfert des données via des pipes et des sockets. Les notifications de io_uring et d'autres producteurs task-work n'interrompent plus ces chemins de collecte.

Cela préserve les données de diagnostic pour une analyse détaillée de l'état de l'application, des mappings et des I/O en attente.

Validation cohérente des quotas DAMON

Les objectifs de quota DAMOS sont validés dans le cœur de DAMON avant d'être appliqués. Les valeurs cibles égales à zéro sont rejetées par le chemin de commit commun, et l'erreur est propagée aux appelants.

Pour les déploiements utilisant une gestion de la mémoire fondée sur DAMON, cela fournit un point de validation cohérent pour la configuration des politiques de quota.

Builds out-of-tree fiables du benchmark DMA

dma_map_benchmark est désormais compilé dans le répertoire de sortie sélectionné lorsque O= est spécifié.

Le benchmark s'intègre aux pipelines de build qui séparent les arborescences des sources des outils générés, permettant une préparation reproductible des diagnostics DMA.

Systèmes d'exploitation pris en charge et installation

HFTKernel prend en charge 24 OS targets parmi Ubuntu, Debian, les plateformes compatibles RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, Amazon Linux, Arch Linux, les déploiements compatibles NixOS, ALT Linux p11 / Simply Linux 11 et Astra Linux 1.8. Amazon Linux 2023 utilise le profil Cloud.

Installation en une seule commande :

curl -fsSL https://hftkernel.com/install.sh | sudo bash

L'installer sélectionne le paquet correspondant au système d'exploitation et le profil de déploiement, puis vérifie l'intégrité des paquets.

Orientation de la version

La base Linux 7.3.1 renforce la progression des I/O, la transmission des timeouts real-time, la gestion du cycle de vie des processus et la cohérence des diagnostics. Ces modifications soutiennent l'objectif de HFTKernel : fournir un hôte prévisible et mesurable pour les applications sensibles à la latency.

Données vDSO préchargées pour un démarrage applicatif prévisible

Le mappage générique des données vDSO peut désormais être peuplé par mlockall(). Le retrait de son indicateur VM_IO permet à la préparation mémoire d'établir les entrées correspondantes des tables de pages avant le début du traitement sensible à la latency.

Pour les applications lisant le temps avec vDSO, cela déplace un défaut de page évitable du premier accès vers la préparation initiale. L'auteur amont a observé environ 20 µs pour le chemin complet de l'exception de défaut de page sur la machine de test.

Cela renforce la préparation des moteurs de trading, des consommateurs d'horodatages et des processus de mesure qui préchargent explicitement leurs jeux de travail.

Moins de contention du verrou LRU pendant la récupération mémoire

La récupération LRU classique calcule désormais les coûts d'équilibrage du balayage anonyme et fichier à partir des compteurs vmstat. L'échantillonnage et la décroissance des coûts utilisent un verrou dédié par lruvec au lieu de reprendre le verrou protégeant les opérations de listes LRU. L'agrégation hiérarchique remplace aussi les mises à jour répétées des coûts parents.

Dans le test amont de pression mémoire sur 176 cœurs et 256 GB, l'attente cumulée du verrou LRU est passée d'environ 4.23 secondes à 1.66 seconde sur une fenêtre de 30 secondes, soit une réduction de 61%, avec des taux de balayage et de récupération similaires.

Pour les déploiements LRU classiques, cela réduit la contention entre le suivi de récupération et les opérations gérant réellement les pages.

Meilleure conservation du code exécutable avec MGLRU

MGLRU promeut les folios mappés de fichiers exécutables après leur première utilisation observée. Le vieillissement des tables de pages et la vérification des références reconnaissent les mappages exécutables lors de la mise à jour de l'état des pages.

Cela protège davantage le code applicatif et les bibliothèques partagées récemment utilisés contre la récupération. La résidence du code devient plus régulière pour les services utilisant MGLRU sous pression mémoire.

Moins de suivi inutile de la pression avec cgroup v2

Le sous-système vmpressure ignore le chemin de notification utilisateur cgroup-v1 lorsqu'il fonctionne sous cgroup v2. La récupération évite ainsi le suivi inutilisé, les verrous, la soumission aux files de travail et les parcours des parents.

Le chemin interne de pression des sockets TCP/SCTP reste actif, et la surveillance utilisateur cgroup-v2 continue via PSI. Cela supprime des tâches d'infrastructure redondantes tout en conservant les signaux de pression utiles au réseau et à la gestion des services.

Sections critiques plus courtes dans les files de travail

Le traitement des files de travail choisit le worker à réveiller sous pool->lock, puis le réveille après libération du verrou. Les opérations de réveil de l'ordonnanceur n'allongent plus la section critique du pool partagé dans les chemins concernés de mise en file et de tâches enchaînées.

Dans un microtest amont sur NVIDIA Grace ARM64 avec des files de travail non liées limitées à NUMA, le throughput est passé de 719,794 à 794,049 tâches par seconde, avec une latency P95 de mise en file réduite de 10.3%.

Cela améliore le traitement des tâches de fond soumises à contention sur les CPU de service et dans l'infrastructure de soutien.

Services gérés par l'ordonnanceur plus réactifs

L'ordonnancement cgroup de la classe fair passe à une seule file de sélection des tâches par CPU, tout en conservant la répartition des poids des groupes. EEVDF améliore aussi l'ordonnancement des tâches à tranches courtes, et l'équilibrage NOHZ privilégie les cœurs entièrement au repos.

Ces changements concernent les passerelles, la surveillance, l'orchestration et les services de maintenance gérés par l'ordonnanceur. La CPU affinity explicite reste le mécanisme de placement des threads de trading dédiés.

Réception zero-copy io_uring plus évolutive

Le sous-système de réception zero-copy io_uring gagne un provisionnement dynamique des zones mémoire et des améliorations coordonnées du remplissage. Le remplissage de grandes pages s'adapte à l'allocation sous-jacente, les entrées compatibles sont regroupées et la tête et la queue de l'anneau occupent des lignes de cache distinctes. La mise en cache de la queue réduit encore les accès à l'état partagé.

Ces changements améliorent la gestion de la mémoire de réception et réduisent le coût du remplissage pour les applications io_uring ZCRX, notamment les données de marché à haut débit et les traitements réseau.

Transmission Solarflare assistée par CXL dans la base amont

Linux 7.3 réunit l'infrastructure CXL Type-2 et l'intégration du pilote Solarflare pour les périphériques compatibles de la famille SFC9100. CONFIG_SFC_CXL active le chemin du pilote CTPIO sur CXL.mem, avec un matériel CXL compatible et un micrologiciel prenant en charge CXL.

Le pilote vérifie les capacités CXL du périphérique, crée une région mémoire CTPIO de 256 MiB et la mappe avec une sémantique de combinaison d'écritures. Cela fournit la prise en charge noyau d'un chemin de transmission hôte-NIC assisté par CXL.

Pour une configuration HFTKernel Hardware correspondante, l'intégration associe CONFIG_SFC, CONFIG_CXL_BUS et CONFIG_SFC_CXL à un serveur, un adaptateur et un micrologiciel compatibles. Elle offre une option ciblée d'optimisation matérielle pour la transmission sensible à la latency.

Contrôle étendu des horloges matérielles

Le pilote DPLL ZL3073x prend désormais en charge une horloge matérielle PTP, exposant la lecture du temps et les ajustements temporels, de fréquence et de phase par les rappels appropriés. Les opérations disponibles suivent l'état actuel du canal, notamment le fonctionnement NCO et le suivi de référence.

Cela élargit les options temporelles matérielles disponibles via les interfaces Linux standard et facilite l'intégration des dispositifs compatibles dans l'infrastructure de gestion des horloges.

Gestion réseau cloud plus évolutive

Certains pilotes réseau logiciels, notamment veth, ipvlan et les tunnels, permettent la désinscription des périphériques par espace de noms réseau. Les mises à jour des règles de routage s'affranchissent aussi du verrou RTNL global. Ces changements réduisent la sérialisation partagée lors des opérations de cycle de vie réseau et de politique de routage.

La prise en charge BIG TCP s'étend aux tunnels UDP comme VXLAN et Geneve. Des lots de segmentation internes plus grands offrent une option supplémentaire d'efficacité pour la distribution massive et la relecture de données sur les réseaux superposés compatibles, tout en préservant le MTU configuré sur le réseau.

Diagnostics multicast plus utiles

RTM_GETMULTICAST indique un nombre d'utilisateurs par groupe. Les logiciels de surveillance peuvent examiner l'utilisation des groupes multicast via netlink, améliorant la visibilité des abonnements sur les hôtes recevant des données de marché multicast.

Profilage des allocations plus efficace

Le profilage des allocations mémoire gagne une interface ioctl binaire pour /proc/allocinfo. Des filtres de module, fonction, fichier et ligne peuvent être appliqués avant l'agrégation des compteurs par CPU, afin de traiter uniquement les sites d'allocation correspondants.

Dans le test amont sur Intel Xeon Platinum 8481C avec 224 CPU logiques, une requête ciblant un fichier a réduit le temps CPU système de 22 ms à 1 ms. Les investigations mémoire ciblées deviennent plus légères et mieux adaptées à la collecte automatisée.

Les nouveaux compteurs pgrotate_anon et pgrotate_file rendent visible le travail de récupération qui ne libère pas immédiatement des pages. Ils servent aux diagnostics LRU classique et MGLRU.

Orientation de la version

La base Linux 7.3 fait progresser trois priorités de HFTKernel : préparer davantage d'état avant la charge, réduire la contention dans les chemins partagés du noyau et améliorer le contrôle du réseau, de la mémoire et du temps.