Notas da versão do HFTKernel 7.3.x.

Progresso oportuno após as barreiras drain do io_uring

Uma solicitação drain independente agora limpa o estado drain quando o flush de sua completion é realizado e não resta outro trabalho adiado. Na execução do io-wq, essa transição ocorre sob o ring lock antes de a completion ficar visível para userspace.

As solicitações enviadas após a barreira concluída podem prosseguir sem esperar que o worker libere sua última referência à solicitação. As solicitações drain encadeadas mantêm seus requisitos de ordenação.

Isso torna os pipelines de I/O orientados a completions mais previsíveis para aplicações que usam barreiras drain.

Wakeups de poll confiáveis e completion multishot

Uma operação atômica compare-and-exchange agora coordena a liberação da propriedade de poll com notificações concorrentes de nova tentativa. Os wakeups pendentes permanecem visíveis, permitindo que o processamento continue sem depender de um evento não relacionado.

Multishot poll também atualiza corretamente o contador de referências compartilhado quando ocorre um hangup. A última passagem de processamento de eventos pode terminar sem repetir o loop desnecessariamente, melhorando o gerenciamento do ciclo de vida das conexões em aplicações assíncronas.

Timeouts precisos da completion queue no PREEMPT_RT

Para tarefas RT e deadline no PREEMPT_RT, os callbacks de timeout da completion queue do io_uring são executados em contexto hard-interrupt. A entrega de wakeups deixa de depender do escalonamento do timer thread de menor prioridade.

No teste upstream com Jetson Orin Nano, com o backport da mudança para o Linux 6.18.39-rt, o atraso máximo caiu de 1,040 µs para 18 µs ao longo de 40,000 deadlines sob carga SCHED_FIFO concorrente. Após a mudança, o atraso de todos os wakeups permaneceu dentro de 100 µs.

Tratamento consistente de provided buffers de recepção grandes

Nas operações de recepção non-bundled que obtêm seu comprimento de um provided buffer, o io_uring limita o comprimento de transferência selecionado a MAX_RW_COUNT.

Isso mantém o comprimento válido ao longo do caminho de retorno com sinal, incluindo provided buffers de 2 GiB ou mais, respeitando o limite existente de tamanho de transferência. Fortalece o tratamento dos buffers de recepção para aplicações que usam regiões reutilizáveis grandes.

Encerramento de workers assíncronos mais bem coordenado

O caminho de saída do io-wq aplica uma memory barrier após publicar seu flag de saída. O encerramento e o task work concorrente de criação de workers respeitam a ordenação necessária, inclusive em arquiteturas fracamente ordenadas.

Isso fortalece a desmontagem ordenada e a reinicialização de serviços que usam pools de workers do io_uring.

O cancelamento de solicitações IORING_OP_WAITID também é idempotente: tentativas repetidas reconhecem o estado de cancelamento existente sem acumular referências adicionais. Isso mantém a consistência das solicitações assíncronas de supervisão de processos durante o cancelamento.

Menos trabalho desnecessário durante a desmontagem de namespaces PID

Durante a limpeza do namespace, o process reaper mascara os wakeups de notificação de task work enquanto aguarda o término dos processos filhos e a liberação dos PIDs.

Ele pode permanecer em espera até que o evento relevante do ciclo de vida ocorra, em vez de retornar repetidamente ao caminho de espera. Isso reduz a atividade evitável de CPU nas interações afetadas entre o encerramento de contêineres e livepatch.

Visibilidade confiável de IRQ por CPU em hosts grandes

/proc/interrupts agora emite seu cabeçalho de CPU sempre que o primeiro registro é renderizado, incluindo novas tentativas após o crescimento do sequence buffer.

A correspondência entre CPU e contadores permanece intacta em sistemas com muitos núcleos. Isso permite uma análise confiável de IRQ, a verificação de sua alocação e o monitoramento das CPUs isoladas e de housekeeping.

Configuração e desmontagem de tracing mais limpas

A configuração de histogramas agora remove os triggers field-variable criados automaticamente quando o comando completo falha. O tracing ativo corresponde à configuração aceita, com a instrumentação temporária removida em vez de continuar contando eventos.

A limpeza de histogramas field-variable mantém a referência estável ao event-file em vez de depender do tempo de vida de outro histograma. Isso melhora a criação, a modificação e a remoção repetidas de sessões de diagnóstico.

A análise de event filters também rejeita expressões lógicas incompletas antes de sua execução. Isso fortalece a configuração automatizada de tracefs e de tracepoints do perf.

Diagnósticos postmortem mais completos

A coleta de core dumps fica protegida contra interrupções por TIF_NOTIFY_SIGNAL durante a transferência de dados por pipes e sockets. As notificações do io_uring e de outros produtores de task work deixam de interromper esses caminhos de coleta.

Isso preserva os dados de diagnóstico para uma análise detalhada do estado da aplicação, dos mappings e da I/O pendente.

Validação consistente de cotas DAMON

As metas de cota do DAMOS são validadas no núcleo do DAMON antes de serem aplicadas. Valores de meta iguais a zero são rejeitados pelo caminho comum de commit, e o erro é propagado aos chamadores.

Para implantações que usam gerenciamento de memória baseado em DAMON, isso oferece um ponto de validação consistente para configurar as políticas de cotas.

Compilações out-of-tree confiáveis do benchmark de DMA

dma_map_benchmark agora é compilado no diretório de saída selecionado quando O= é especificado.

O benchmark se integra a pipelines de compilação que separam as árvores de código-fonte das ferramentas geradas, permitindo preparar os diagnósticos de DMA de forma reproduzível.

Sistemas operacionais compatíveis e instalação

O HFTKernel oferece suporte a 24 OS targets que abrangem Ubuntu, Debian, plataformas compatíveis com RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, Amazon Linux, Arch Linux, implantações compatíveis com NixOS, ALT Linux p11 / Simply Linux 11 e Astra Linux 1.8. O Amazon Linux 2023 usa o perfil Cloud.

Instale com um único comando:

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

O instalador seleciona o pacote correspondente ao sistema operacional e o perfil de implantação, e verifica a integridade do pacote.

Foco da versão

A base Linux 7.3.1 fortalece o progresso de I/O, a entrega de timeouts em tempo real, o gerenciamento do ciclo de vida dos processos e a consistência dos diagnósticos. Essas mudanças apoiam o objetivo do HFTKernel de oferecer um host previsível e mensurável para aplicações sensíveis à latency.

Dados vDSO com páginas pré-carregadas para início previsível das aplicações

O mapeamento genérico de dados vDSO agora pode ser materializado por mlockall(). A remoção de seu indicador VM_IO permite que a fase de preparação da memória estabeleça as entradas correspondentes da tabela de páginas antes do início do processamento sensível à latency.

Para aplicações que usam leituras de tempo assistidas por vDSO, isso transfere uma falha de página evitável de first-touch para a preparação inicial. O autor upstream observou aproximadamente 20 µs para o caminho completo da exceção de falha de página na máquina de teste.

Isso fortalece a preparação de motores de negociação, consumidores de marcas de tempo e processos de medição que pré-carregam explicitamente as páginas de seus conjuntos de trabalho.

Menor contenção do bloqueio LRU durante a recuperação de memória

A recuperação LRU clássica agora obtém os custos de balanceamento da varredura anônima e de arquivos a partir dos contadores vmstat. A amostragem e a redução dos custos usam um bloqueio dedicado por lruvec em vez de adquirir repetidamente o bloqueio que protege as operações das listas LRU. A agregação de hierarquias também substitui atualizações repetidas de custos nos níveis superiores.

No teste upstream de pressão de memória com 176 núcleos e 256 GB, a espera agregada pelo bloqueio LRU caiu de aproximadamente 4.23 segundos para 1.66 segundos durante uma janela de registro de 30 segundos, uma redução de 61%, com taxas semelhantes de varredura e recuperação.

Para implantações com LRU clássica, isso reduz a contenção entre a contabilização da recuperação e as operações que realmente gerenciam as páginas.

Maior retenção do código executável com MGLRU

O MGLRU promove folios de arquivos executáveis mapeados após o primeiro uso observado. Tanto o envelhecimento de tabelas de páginas quanto a verificação de referências reconhecem mapeamentos executáveis ao atualizar o estado das páginas.

Isso oferece maior proteção contra recuperação ao código de aplicações e de bibliotecas compartilhadas usado recentemente. Favorece uma residência mais consistente do código para serviços executados com MGLRU sob pressão de memória.

Menos trabalho desnecessário de contabilização de pressão em cgroup v2

O subsistema vmpressure ignora o caminho de notificação ao espaço de usuário de cgroup-v1 quando executado sob cgroup v2. A recuperação evita contabilização, bloqueios, envios a filas de trabalho e percursos de ancestrais que não são utilizados.

O caminho de pressão de sockets TCP/SCTP dentro do kernel permanece ativo, e o monitoramento de pressão no espaço de usuário de cgroup-v2 continua por meio de PSI. Isso remove trabalho redundante de infraestrutura e mantém os sinais de pressão usados pela rede e pelo gerenciamento de serviços.

Seções críticas mais curtas nas filas de trabalho

O processamento de filas de trabalho seleciona o trabalhador a ser ativado enquanto mantém pool->lock e realiza a ativação depois de liberá-lo. As operações de ativação do escalonador deixam de prolongar a seção crítica do grupo compartilhado nos caminhos afetados de enfileiramento e trabalho encadeado.

Em um microteste upstream de NVIDIA Grace ARM64 com filas de trabalho não vinculadas e escopo NUMA, o throughput aumentou de 719,794 para 794,049 itens de trabalho por segundo, com latency de enfileiramento P95 10.3% menor.

Isso melhora o tratamento de trabalho em segundo plano com contenção nas CPUs de manutenção e na infraestrutura de apoio.

Serviços gerenciados pelo escalonador mais responsivos

O escalonamento de cgroups da classe justa passa a usar uma única fila de execução de seleção de tarefas por CPU, mantendo a distribuição de pesos dos grupos. O EEVDF também melhora o escalonamento de tarefas com fatias curtas, e o balanceamento NOHZ prefere núcleos totalmente ociosos.

Essas alterações são relevantes para gateways, monitoramento, orquestração e serviços de manutenção gerenciados pelo escalonador. CPU affinity explícita continua sendo o mecanismo de posicionamento para threads dedicadas de negociação.

Recepção zero-copy do io_uring mais escalável

O subsistema de recepção zero-copy do io_uring ganha provisionamento dinâmico de áreas de memória e melhorias coordenadas de reposição. A reposição de páginas grandes escala com a alocação subjacente, entradas de reposição compatíveis são agrupadas, e a cabeça e a cauda do anel de reposição ocupam linhas de cache separadas. O armazenamento em cache da cauda reduz ainda mais os acessos ao estado compartilhado.

Essas alterações melhoram o gerenciamento da memória de recepção e reduzem a sobrecarga de reposição para aplicações que usam io_uring ZCRX, incluindo cargas de dados de mercado de alta frequência e processamento de rede.

Suporte à transmissão Solarflare assistida por CXL na base upstream

O Linux 7.3 reúne a infraestrutura CXL Type-2 e a integração do driver Solarflare para dispositivos compatíveis da família SFC9100. CONFIG_SFC_CXL habilita o caminho do driver para CTPIO sobre CXL.mem, com hardware CXL compatível e firmware com suporte a CXL.

O driver verifica os recursos do dispositivo CXL, cria uma região de memória CTPIO de 256 MiB e a mapeia com semântica de combinação de gravações. Isso habilita no kernel um caminho de transmissão do host para a NIC assistido por CXL.

Para uma configuração HFTKernel Hardware correspondente, a integração combina CONFIG_SFC, CONFIG_CXL_BUS e CONFIG_SFC_CXL com um servidor, adaptador e firmware compatíveis. Isso cria uma opção específica de otimização de hardware para transmissão sensível à latency.

Controle ampliado do relógio de hardware

O driver DPLL ZL3073x ganha suporte ao relógio de hardware PTP, expondo leituras de tempo, ajuste de tempo, ajuste de frequência e ajuste de fase pelos callbacks apropriados. As operações disponíveis seguem o estado atual do canal, incluindo operação NCO e rastreamento de referências.

Isso amplia as opções de temporização de hardware disponíveis pelas interfaces padrão do Linux e facilita a integração de dispositivos de temporização compatíveis à infraestrutura de gerenciamento de relógios.

Gerenciamento de rede na nuvem mais escalável

Determinados drivers de rede de software, incluindo veth, ipvlan e túneis, passam a permitir a remoção do registro de dispositivos por namespace de rede. As atualizações de regras de roteamento também deixam de depender do bloqueio RTNL global. Essas alterações reduzem a serialização compartilhada durante as operações do ciclo de vida da rede e das políticas de roteamento.

O suporte a BIG TCP se estende a túneis UDP como VXLAN e Geneve. Lotes internos maiores de segmentação oferecem uma opção adicional de eficiência para distribuição e reprodução em massa de dados sobre redes sobrepostas compatíveis, preservando a MTU configurada na rede física.

Diagnósticos multicast mais úteis

RTM_GETMULTICAST informa uma contagem de usuários por grupo. O software de monitoramento pode examinar o uso de grupos multicast por netlink, melhorando a visibilidade do estado de inscrição em hosts que recebem dados de mercado multicast.

Análise de alocações mais eficiente

A análise de alocações de memória ganha uma interface ioctl binária para /proc/allocinfo. Filtros de módulo, função, arquivo e linha podem ser aplicados antes da agregação dos contadores por CPU, para que as consultas de diagnóstico processem apenas os pontos de alocação correspondentes.

No teste upstream com Intel Xeon Platinum 8481C e 224 CPUs lógicas, uma consulta a um arquivo específico reduziu o tempo de CPU do sistema de 22 ms para 1 ms. Isso torna as investigações específicas de memória mais leves e adequadas à coleta automatizada.

Os novos contadores pgrotate_anon e pgrotate_file acrescentam visibilidade sobre o trabalho de recuperação que não libera páginas imediatamente. Eles dão suporte a diagnósticos tanto de LRU clássica quanto de MGLRU.

Foco da versão

A base Linux 7.3 avança em três prioridades do HFTKernel: preparar mais estado antes do início da carga de trabalho, reduzir a contenção nos caminhos compartilhados do kernel e oferecer maior controle sobre rede, memória e temporização.