Notas de la versión de HFTKernel 7.3.x.

Progreso oportuno después de las barreras drain de io_uring

Una solicitud drain independiente ahora borra el estado drain cuando se realiza el flush de su completion y no queda otro trabajo diferido. En la ejecución de io-wq, esa transición se realiza bajo el ring lock antes de que la completion sea visible para userspace.

Las solicitudes enviadas después de la barrera completada pueden avanzar sin esperar a que el worker libere su última referencia a la solicitud. Las solicitudes drain enlazadas conservan sus requisitos de ordenación.

Esto hace más predecibles los pipelines de I/O impulsados por completions para las aplicaciones que utilizan barreras drain.

Wakeups de poll fiables y completion multishot

Una operación atómica compare-and-exchange coordina ahora la liberación de la propiedad de poll con las notificaciones de reintento concurrentes. Los wakeups pendientes permanecen visibles, lo que permite continuar el procesamiento sin depender de un evento ajeno.

Multishot poll también actualiza correctamente el contador de referencias compartido al producirse un hangup. La última pasada de procesamiento de eventos puede completarse sin repetir el bucle innecesariamente, lo que mejora la gestión del ciclo de vida de las conexiones en aplicaciones asíncronas.

Timeouts precisos de la completion queue en PREEMPT_RT

Para las tareas RT y deadline en PREEMPT_RT, los callbacks de timeout de la completion queue de io_uring se ejecutan en contexto hard-interrupt. La entrega de wakeups ya no depende de la planificación del timer thread de menor prioridad.

En la prueba upstream con Jetson Orin Nano, con el cambio aplicado mediante backport a Linux 6.18.39-rt, el retraso máximo se redujo de 1,040 µs a 18 µs en 40,000 deadlines bajo carga SCHED_FIFO concurrente. Tras el cambio, el retraso de todos los wakeups se mantuvo dentro de 100 µs.

Gestión coherente de provided buffers de recepción grandes

En las operaciones de recepción non-bundled cuya longitud se obtiene de un provided buffer, io_uring limita la longitud de transferencia seleccionada a MAX_RW_COUNT.

Esto mantiene una longitud válida a través de la ruta de retorno con signo, incluidos los provided buffers de 2 GiB o más, respetando el límite existente del tamaño de transferencia. Refuerza la gestión de los buffers de recepción para las aplicaciones que utilizan regiones reutilizables grandes.

Cierre de workers asíncronos mejor coordinado

La ruta de salida de io-wq aplica una memory barrier después de publicar su flag de salida. El cierre y el task work concurrente de creación de workers respetan la ordenación requerida, incluso en arquitecturas débilmente ordenadas.

Esto refuerza el desmontaje ordenado y el reinicio de los servicios que utilizan pools de workers de io_uring.

La cancelación de solicitudes IORING_OP_WAITID también es idempotente: los intentos repetidos reconocen el estado de cancelación existente sin acumular referencias adicionales. Esto mantiene la coherencia de las solicitudes asíncronas de supervisión de procesos durante la cancelación.

Menos trabajo innecesario durante el desmontaje de namespaces PID

Durante la limpieza del namespace, el process reaper enmascara los wakeups de notificación de task work mientras espera la terminación de los procesos hijos y la liberación de los PID.

Puede permanecer en espera hasta que ocurra el evento pertinente del ciclo de vida, en lugar de volver repetidamente a su ruta de espera. Esto reduce la actividad de CPU evitable en las interacciones afectadas entre el cierre de contenedores y livepatch.

Visibilidad fiable de IRQ por CPU en hosts grandes

/proc/interrupts ahora emite su cabecera de CPU cada vez que se representa el primer registro, incluidos los reintentos después de que crezca el sequence buffer.

La correspondencia entre CPU y contadores se mantiene intacta en sistemas con un gran número de núcleos. Esto permite un análisis fiable de IRQ, la verificación de su ubicación y la monitorización de las CPU aisladas y de housekeeping.

Configuración y desmontaje de tracing más limpios

La configuración de histogramas ahora elimina los triggers field-variable creados automáticamente cuando falla el comando completo. El tracing activo corresponde a la configuración aceptada, y la instrumentación temporal se limpia en lugar de seguir contando eventos.

La limpieza de histogramas field-variable conserva la referencia estable al event-file en lugar de depender del tiempo de vida de otro histograma. Esto mejora la creación, modificación y eliminación repetidas de sesiones de diagnóstico.

El análisis de event filters también rechaza las expresiones lógicas incompletas antes de que lleguen a ejecutarse. Esto refuerza la configuración automatizada de tracefs y de tracepoints de perf.

Diagnósticos postmortem más completos

La recopilación de core dumps está protegida frente a interrupciones por TIF_NOTIFY_SIGNAL durante la transferencia de datos mediante pipes y sockets. Las notificaciones de io_uring y de otros productores de task work ya no interrumpen esas rutas de recopilación.

Esto conserva los datos de diagnóstico para analizar en detalle el estado de la aplicación, los mappings y la I/O pendiente.

Validación coherente de cuotas DAMON

Los objetivos de cuota de DAMOS se validan en el núcleo de DAMON antes de aplicarse. Los valores objetivo de cero se rechazan a través de la ruta común de commit, y el error se propaga a quienes la invocan.

En los despliegues que utilizan gestión de memoria basada en DAMON, esto proporciona un punto de validación coherente para configurar las políticas de cuotas.

Compilaciones out-of-tree fiables del benchmark de DMA

dma_map_benchmark ahora se compila en el directorio de salida seleccionado cuando se especifica O=.

El benchmark se integra en pipelines de compilación que separan los árboles de código fuente de las herramientas generadas, lo que permite preparar los diagnósticos de DMA de forma reproducible.

Sistemas operativos compatibles e instalación

HFTKernel admite 24 OS targets que abarcan Ubuntu, Debian, plataformas compatibles con RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, Amazon Linux, Arch Linux, despliegues compatibles con NixOS, ALT Linux p11 / Simply Linux 11 y Astra Linux 1.8. Amazon Linux 2023 utiliza el perfil Cloud.

Instale con un solo comando:

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

El instalador selecciona el paquete correspondiente al sistema operativo y el perfil de despliegue, y verifica la integridad del paquete.

Enfoque de la versión

La base Linux 7.3.1 refuerza el progreso de I/O, la entrega de timeouts en tiempo real, la gestión del ciclo de vida de los procesos y la coherencia de los diagnósticos. Estos cambios respaldan el objetivo de HFTKernel de ofrecer un host predecible y medible para aplicaciones sensibles a la latency.

Datos vDSO con páginas precargadas para un inicio predecible de las aplicaciones

El mapeo genérico de datos vDSO ahora puede materializarse mediante mlockall(). La eliminación de su indicador VM_IO permite que la fase de preparación de memoria establezca las entradas correspondientes de la tabla de páginas antes de que comience el procesamiento sensible a la latency.

Para las aplicaciones que utilizan lecturas de tiempo asistidas por vDSO, esto traslada un fallo de página evitable de first-touch a la preparación inicial. El autor upstream observó aproximadamente 20 µs para la ruta completa de excepción por fallo de página en la máquina de prueba.

Esto refuerza la preparación de motores de trading, consumidores de marcas de tiempo y procesos de medición que precargan explícitamente las páginas de sus conjuntos de trabajo.

Menor contención del bloqueo LRU durante la recuperación de memoria

La recuperación LRU clásica ahora obtiene los costos de balanceo del escaneo anónimo y de archivos a partir de contadores vmstat. El muestreo y la disminución de costos utilizan un bloqueo dedicado por lruvec en lugar de adquirir repetidamente el bloqueo que protege las operaciones de las listas LRU. La agregación de jerarquías también sustituye las actualizaciones repetidas de costos en los niveles superiores.

En la prueba upstream de presión de memoria con 176 núcleos y 256 GB, la espera agregada del bloqueo LRU disminuyó de aproximadamente 4.23 segundos a 1.66 segundos durante una ventana de registro de 30 segundos, una reducción del 61%, con tasas similares de escaneo y recuperación.

Para implementaciones con LRU clásica, esto reduce la contención entre la contabilidad de recuperación y las operaciones que realmente administran las páginas.

Mayor retención del código ejecutable con MGLRU

MGLRU promociona los folios de archivos ejecutables mapeados tras su primer uso observado. Tanto el envejecimiento de tablas de páginas como la comprobación de referencias reconocen los mapeos ejecutables al actualizar el estado de las páginas.

Esto proporciona mayor protección frente a la recuperación al código de aplicaciones y bibliotecas compartidas utilizado recientemente. Favorece una residencia más uniforme del código en servicios que funcionan con MGLRU bajo presión de memoria.

Menos trabajo innecesario de contabilidad de presión en cgroup v2

El subsistema vmpressure omite la ruta de notificación al espacio de usuario de cgroup-v1 cuando se ejecuta bajo cgroup v2. La recuperación evita contabilidad, bloqueos, envíos a colas de trabajo y recorridos de ancestros que no se utilizan.

La ruta de presión de sockets TCP/SCTP dentro del kernel permanece activa, y la supervisión de presión en el espacio de usuario de cgroup-v2 continúa mediante PSI. Esto elimina trabajo redundante de infraestructura y conserva las señales de presión utilizadas por la red y la gestión de servicios.

Secciones críticas más cortas en las colas de trabajo

El procesamiento de colas de trabajo selecciona el trabajador que debe activar mientras mantiene pool->lock y realiza la activación después de liberarlo. Las operaciones de activación del planificador ya no prolongan la sección crítica del grupo compartido en las rutas afectadas de encolado y trabajo encadenado.

En una microprueba upstream de NVIDIA Grace ARM64 con colas de trabajo no vinculadas y alcance NUMA, el throughput aumentó de 719,794 a 794,049 elementos de trabajo por segundo, con una latency de encolado P95 un 10.3% menor.

Esto mejora la gestión del trabajo en segundo plano con contención en las CPU de mantenimiento y en la infraestructura de apoyo.

Servicios gestionados por el planificador más ágiles

La planificación de cgroups de clase justa pasa a una única cola de ejecución de selección de tareas por CPU, manteniendo la distribución de pesos de los grupos. EEVDF también mejora la planificación de tareas con intervalos cortos, y el balanceo NOHZ prefiere núcleos completamente inactivos.

Estos cambios son relevantes para puertas de enlace, supervisión, orquestación y servicios de mantenimiento gestionados por el planificador. CPU affinity explícita sigue siendo el mecanismo de ubicación para los hilos dedicados de trading.

Recepción zero-copy de io_uring más escalable

El subsistema de recepción zero-copy de io_uring incorpora aprovisionamiento dinámico de áreas de memoria y mejoras coordinadas de reposición. La reposición de páginas grandes escala con la asignación subyacente, las entradas de reposición compatibles se agrupan y la cabecera y la cola del anillo de reposición ocupan líneas de caché separadas. El almacenamiento en caché de la cola reduce aún más los accesos al estado compartido.

Estos cambios mejoran la gestión de memoria de recepción y reducen la sobrecarga de reposición para aplicaciones que utilizan io_uring ZCRX, incluidas cargas de datos de mercado de alta frecuencia y procesamiento de red.

Compatibilidad de transmisión Solarflare asistida por CXL en la base upstream

Linux 7.3 reúne la infraestructura CXL Type-2 y la integración del driver Solarflare para dispositivos compatibles de la familia SFC9100. CONFIG_SFC_CXL habilita la ruta del driver para CTPIO sobre CXL.mem, con hardware CXL compatible y firmware con soporte CXL.

El driver verifica las capacidades del dispositivo CXL, crea una región de memoria CTPIO de 256 MiB y la mapea con semántica de combinación de escrituras. Esto habilita en el kernel una ruta de transmisión del host a la NIC asistida por CXL.

Para una configuración HFTKernel Hardware correspondiente, la integración combina CONFIG_SFC, CONFIG_CXL_BUS y CONFIG_SFC_CXL con un servidor, adaptador y firmware compatibles. Esto crea una opción de optimización de hardware específica para transmisión sensible a la latency.

Control ampliado del reloj de hardware

El driver DPLL ZL3073x incorpora compatibilidad con el reloj de hardware PTP, exponiendo lecturas de tiempo, ajuste de tiempo, ajuste de frecuencia y ajuste de fase mediante las funciones de retorno adecuadas. Las operaciones disponibles siguen el estado actual del canal, incluido el funcionamiento NCO y el seguimiento de referencias.

Esto amplía las opciones de temporización de hardware disponibles mediante interfaces estándar de Linux y facilita la integración de dispositivos de temporización compatibles en la infraestructura de gestión de relojes.

Gestión de red en la nube más escalable

Determinados drivers de red de software, incluidos veth, ipvlan y túneles, incorporan la baja de dispositivos por espacio de nombres de red. Las actualizaciones de reglas de enrutamiento también dejan de depender del bloqueo RTNL global. Estos cambios reducen la serialización compartida durante las operaciones del ciclo de vida de la red y de las políticas de enrutamiento.

La compatibilidad con BIG TCP se extiende a túneles UDP como VXLAN y Geneve. Los lotes internos de segmentación más grandes proporcionan una opción adicional de eficiencia para distribución y reproducción masiva de datos sobre redes superpuestas compatibles, conservando la MTU configurada en la red física.

Diagnósticos multicast más útiles

RTM_GETMULTICAST informa de un recuento de usuarios por grupo. El software de supervisión puede examinar el uso de grupos multicast mediante netlink, mejorando la visibilidad del estado de suscripción en hosts que reciben datos de mercado multicast.

Análisis de asignaciones más eficiente

El análisis de asignaciones de memoria incorpora una interfaz ioctl binaria para /proc/allocinfo. Los filtros de módulo, función, archivo y línea pueden aplicarse antes de agregar los contadores por CPU, de modo que las consultas de diagnóstico procesen únicamente los puntos de asignación coincidentes.

En la prueba upstream con Intel Xeon Platinum 8481C y 224 CPU lógicas, una consulta de un archivo específico redujo el tiempo de CPU del sistema de 22 ms a 1 ms. Esto hace que las investigaciones específicas de memoria sean más ligeras y adecuadas para la recolección automatizada.

Los nuevos contadores pgrotate_anon y pgrotate_file aportan visibilidad del trabajo de recuperación que no libera páginas inmediatamente. Admiten diagnósticos tanto de LRU clásica como de MGLRU.

Enfoque de la versión

La base Linux 7.3 impulsa tres prioridades de HFTKernel: preparar más estado antes de que comience la carga de trabajo, reducir la contención en las rutas compartidas del kernel y ofrecer mayor control de red, memoria y temporización.