Além de todas as atualizações interessantes de drivers gráficos de código aberto que vêm com o Linux 6.6, como AMD FreeSync Panel Replay, adições de Nouveau uAPI para NVK, Intel PSR para laptops antigos e muitas outras alterações de driver de GPU, o subsistema Direct Rendering Manager (DRM) com sua estrutura/subsistema “accel” do acelerador AI está lançando suporte inicial para o VPU4 que vem com os processadores Intel Lunar Lake.De volta ao Linux 6.3, o driver Intel VPU foi introduzido por oferecer suporte ao bloco de hardware AI “Versatile Processing Unit” estreando com processadores Meteor Lake.
Antes mesmo dos processadores Meteor Lake serem lançados, os engenheiros de driver de código aberto da Intel já começaram a habilitar o bloco IP “VPU4” que virá duas gerações depois com o Lunar Lake.Desde o mês passado, a Intel começou a estender seu código de driver Linux iVPU para implementar este suporte VPU “VPU IP 4” de última geração.
Linux 6.6 traz suporte para VPU4 da Intel Lunar Lake
Com o drm-misc-next pull da semana passada, esse suporte inicial ao VPU4 está presente e, portanto, sendo introduzido no ciclo do kernel Linux 6.6.
Suspeito que mais habilitações do VPU4 ocorrerão nos próximos ciclos do kernel, mas é bom ver esse suporte inicial do mecanismo VPU AI para o Lunar Lake já sendo iniciado para este driver de código aberto. Enquanto isso, com os próximos processadores Meteor Lake, estamos ansiosos para experimentar esta VPU inicial e ver como ela funciona com o OpenVINO e outras cargas de trabalho de IA suportadas.
IO_uring adiciona suporte para FUTEX Vetorizadas no Linux 6.6
Com o próximo ciclo do Linux 6.6, outra mudança empolgante foi recentemente incluída na ramificação “for-next” do subsistema de blocos: IO_uring futex/futexv support.O especialista em armazenamento Linux e desenvolvedor líder do IO_uring, Jens Axboe, na semana passada, enfileirou seu código no ramo for-next do linux-block.git para permitir esperas FUTEX vetorizadas.
Em patches anteriores sobre esse suporte futex/futexv em IO_uring, Axboe explicou:
Tanto quanto me lembro, o primeiro pedido de suporte futex com io_uring veio de Andres Freund, trabalhando em postgres. Seu retrabalho aio do postgres foi um dos primeiros a adotar o io_uring, e o suporte ao futex foi uma extensão natural para isso. Isso é relevante tanto do ponto de vista da usabilidade quanto da eficiência e do desempenho.
Nas palavras de Andres, para o primeiro:
“O suporte à espera Futex em io_uring torna muito mais fácil evitar deadlocks em programas concorrentes que possuem seu próprio buffer pool: Obviamente, as páginas no buffer pool do aplicativo devem ser bloqueadas durante o IO. Se o iniciador do IO A precisa esperar por um bloqueio retido B, o detentor do bloqueio B pode esperar que o IO A seja concluído. A capacidade de esperar por um bloqueio e conclusões de IO ao mesmo tempo fornece uma maneira eficiente de evitar tais impasses.”e em termos de eficiência, mesmo sem desbloquear todo o potencial ainda, Andres diz:”Futex wake support in io_uring é útil porque permite ativações direcionadas mais eficientes. Para alguns “bloqueios”, o postgres tem filas implementadas no espaço do usuário, com lógica de ativação que não pode ser facilmente implementado com FUTEX_WAKE_BITSET em uma única “palavra futex” (imagine esperar que as liberações de diário sejam concluídas até um determinado ponto). Portanto, uma “liberação de bloqueio” às vezes precisa ativar muitos processos em uma linha. -dirty para fazer essas ativações via io_uring leva a um aumento de 3% na taxa de transferência, com 12% menos trocas de contexto, embora em uma carga de trabalho bastante extrema.”
Um bom aumento de eficiência e desempenho ao usar o suporte IO_uring futex/futexv.
Também na fila dessa ramificação na semana passada está o suporte IO_uring IORING_OP_WAITID. O IORING_OP_WAITID é uma versão totalmente assíncrona do waitid.
O Linux 6.6 está se preparando para ser outro ciclo emocionante do kernel, com este kernel estreando no final do ano.