Linux kernel 7.2: novidades e impacto num VPS

Novidades do Linux kernel 7.2

O Linux kernel 7.2 foi lançado em 16 August 2026, e a alteração que merece atenção é o escalonamento consciente da cache, implementado por trás da nova opção CONFIG_SCHED_CACHE. O escalonador tenta agora manter as threads de um processo nos CPUs que partilham a mesma cache de último nível (LLC). Nenhuma outra alteração desta versão muda a forma como a carga de trabalho é colocada num CPU.

O restante do 7.2, numa linha: uma reformulação do caminho de fast commit do ext4, melhorias no MGLRU (o código de recuperação de memória least recently used com várias gerações), um novo destino dm-inlinecrypt do device mapper para encriptação inline de dispositivos de bloco e a remoção da última chamada strncpy() do código-fonte do kernel.

Um facto determina se a funcionalidade principal pode fazer alguma coisa por si, por isso aparece primeiro. O balanceamento de carga consciente da cache só é ativado quando um nó NUMA (non-uniform memory access) contém mais de uma LLC. Normalmente, um guest VPS não apresenta esse esquema ao sistema operativo, pelo que, na maioria dos guests, o código é compilado mas nunca é utilizado. Pode verificar isso com dois comandos, na secção "Um guest VPS vê alguma destas alterações?" abaixo.

Todas as afirmações técnicas desta página vêm do changelog do 7.2 e da própria série de patches do escalonamento consciente da cache, consultados em 18 August 2026. As fontes estão listadas perto do fim, para que possa compará-las com o comportamento do seu próprio kernel.

Por que o escalonador precisava de conhecer as caches

Um socket de servidor moderno não tem uma única cache de último nível. Um pacote AMD EPYC é composto por vários complexos de núcleos, e cada complexo tem a sua própria L3. Os processadores Intel Xeon recentes também dividem um socket em mais de um domínio de cache. Assim, um único nó NUMA pode conter quatro, oito ou mais LLCs separadas, e duas threads do mesmo programa podem acabar em caches diferentes.

Essa colocação tem um custo de tempo. Quando duas threads partilham uma página a partir de LLCs diferentes, cada cache mantém a sua própria cópia da linha. Uma escrita de um lado invalida a cópia do outro lado, pelo que a leitura seguinte tem de atravessar a interconexão ou aceder à memória principal. Isto é cache bouncing. Manifesta-se como ciclos passados à espera, não como tempo de CPU ocioso, por isso é fácil não o detetar quando se observa a média de carga.

Antes da 7.2, o balanceador de carga colocava as tarefas com base na carga, na utilização e nas CPUs ociosas. Não recebia nenhuma informação que indicasse "estas duas tarefas leem a mesma memória". A 7.2 adiciona essa informação usando uma aproximação sem custo de cálculo: as threads de um processo partilham um espaço de endereçamento, pelo que é provável que partilhem dados.

Como o kernel escolhe uma LLC preferencial

O registo fica associado ao processo, em mm_struct, a estrutura do kernel que representa um espaço de endereçamento. Periodicamente, o kernel recolhe amostras sobre onde estão a ser executadas as threads desse processo e contabiliza, por LLC, quanto do processo está em cada uma. A LLC que contém a maior parte torna-se a LLC preferencial de todo o processo. É esse valor único que as decisões posteriores consultam.

Depois, há dois caminhos que usam essa informação. Ao acordar uma tarefa, o scheduler dá preferência a uma CPU na LLC preferencial do processo, em vez de escolher qualquer CPU livre no nó. Durante o balanceamento de carga, quando é necessário mover tarefas entre grupos do scheduler, dá preferência às tarefas que já preferem a LLC de destino e evita afastar uma tarefa da LLC que ela prefere.

As proteções são tão importantes como a funcionalidade. Concentrar todas as threads de um processo ocupado num único domínio de cache pode sobrecarregar esse domínio enquanto o resto do socket permanece inativo. Os parâmetros ajustáveis ficam no debugfs, o sistema de ficheiros de depuração do kernel, em /sys/kernel/debug/sched/:

• llc_aggr_tolerance, um valor de 0 a 100, define a intensidade com que o kernel agrega. 0 desativa o agendamento consciente da cache em tempo de execução. 1 é a configuração conservadora: um processo cujo RSS (resident set size, a sua memória residente) seja maior do que a LLC, ou que execute mais threads do que o número de cores da LLC, permanece onde está. 100 agrega independentemente do tamanho ou do número de threads.
• llc_overload_pct, com o valor predefinido 50, define a utilização média acima da qual a LLC preferencial é considerada ocupada.
• llc_imb_pct, com o valor predefinido 20, limita o desequilíbrio que uma migração de agregação pode criar quando a LLC preferencial ultrapassa esse nível de sobrecarga.
• llc_epoch_period, com o valor predefinido 10 ms, define a frequência com que a ocupação é recolhida.
• llc_epoch_affinity_timeout, com o valor predefinido 50 ms, define durante quanto tempo um processo inativo mantém a sua preferência antes de o kernel a remover.

Leia os seus próprios valores antes de alterar qualquer um deles, porque uma distribuição pode fornecer valores predefinidos diferentes: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Quais cargas de trabalho podem beneficiar e quais não beneficiam

Os números abaixo são os valores publicados com a série de patches. Foram medidos em hardware de classe servidor, e alguns com o parâmetro de tolerância ajustado para um valor agressivo. Considere-os como o melhor caso em bare metal, não como uma promessa para o seu sistema.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

O Hackbench com um único grupo melhorou 30.57%, e o teste de throughput do ChaCha20 em AMD Genoa melhorou 44%. Todos os 3 resultados foram obtidos em hardware servidor com vários LLC, controlado integralmente pelo responsável pelos testes.

O perfil de uma carga de trabalho que beneficia é o seguinte:

• Mais de uma thread num único processo, para haver algo que possa ser agrupado.
• Partilha real entre essas threads, para que uma linha de cache transferida represente um custo efetivo.
• Um working set que caiba num único LLC, porque não é possível dar localidade de cache a um processo maior do que a cache movendo-o.
• Capacidade livre na máquina, para que o scheduler possa escolher onde colocar a próxima thread.

E os casos em que não há benefício:

• Uma máquina que já esteja na capacidade máxima. Todas as CPUs estão ocupadas, por isso a colocação é forçada e os ganhos reportados diminuem.
• Processos single-threaded e pools de processos independentes que não partilham dados.
• Um working set muito maior do que o LLC, que a configuração cuidadosa llc_aggr_tolerance ignora deliberadamente.
• Um nó que reporte um único LLC, onde a funcionalidade nunca é ativada.

Também existe um custo, e a série deixa isso claro. A recolha da ocupação é trabalho executado no contexto da tarefa. Em alguns testes, a latência dos pedidos piorou porque esse trabalho atrasou o regresso da tarefa ao espaço de utilizador. A agregação também pode aumentar a variância da latência, mesmo quando o throughput médio melhora. Se a latência de cauda for mais importante do que a média, meça a sua própria latência de cauda.

Uma VM convidada num VPS vê alguma destas informações

Dois factos determinam a resposta.

Primeiro, a funcionalidade depende da topologia. O balanceamento de carga consciente da cache só é ativado quando existe mais de uma LLC dentro de um nó NUMA, e o kernel regista isso durante a configuração da topologia. Quando um nó indica uma única LLC, o caminho consciente da cache permanece inativo, independentemente da configuração dos parâmetros ajustáveis.

Segundo, a topologia de cache que a VM convidada lê não é a do host. É a topologia apresentada pelo modelo de CPU do hypervisor. Uma VM convidada KVM (kernel based virtual machine) predefinida normalmente não recebe a disposição real da cache L3 do host. Por isso, a VM trabalha com uma representação simplificada.

Verifique o que a sua própria VM convidada vê:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3 é a cache L3 na maioria das CPUs x86. Uma linha que liste todas as vCPUs significa que a VM convidada vê uma única LLC. Nesse caso, a funcionalidade não tem nada para organizar. No such file or directory significa que nenhuma L3 foi exposta à VM convidada. Nesse caso, a VM trata um nível de cache inferior como o seu último nível, com limites inventados pelo hypervisor, e não com os limites existentes no silício.

Depois existe o agendamento duplo, que é a ressalva relevante para qualquer tenant. O kernel da VM convidada coloca as threads nas vCPUs. O kernel do host coloca essas threads de vCPU nos cores físicos. Uma VM convidada que agrupe cuidadosamente quatro threads nas vCPUs 0 a 3 está a expressar uma preferência sobre quatro threads do host. O host pode colocá-las em diferentes domínios físicos de cache e movê-las mais tarde. A decisão da VM convidada não está errada. Simplesmente não é a decisão final. Este é o mesmo limite entre camadas que produz o steal time que um vizinho ruidoso deixa nas suas vCPUs.

Então, onde chega esta funcionalidade para um tenant de VPS? Em dois pontos. Em planos onde a topologia é real e não sintética, como cores dedicados ou instâncias maiores com uma disposição exposta diretamente, o scheduler da VM convidada está a tomar uma decisão sobre hardware existente. E no kernel do host do fornecedor, onde o posicionamento consciente da cache das suas threads de vCPU é uma vantagem que cabe ao fornecedor aproveitar, não a si. A disposição da cache também varia entre arquiteturas. Esta é mais uma variável ao comparar um VPS Arm com um VPS x86.

Medir o comportamento da cache dentro de uma VM convidada é mais difícil do que num servidor físico. perf stat -e cache-misses normalmente apresenta <not supported> porque o hypervisor não expõe a PMU (performance monitoring unit) às VMs convidadas. Em vez disso, meça o throughput e a latência da sua própria aplicação. Use o parâmetro de debugfs como interruptor entre as duas execuções.

Verifique se o kernel tem CONFIG_SCHED_CACHE

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y significa que o kernel foi compilado com essa opção. Uma linha com # CONFIG_SCHED_CACHE is not set significa que a opção existe nessa versão, mas foi desativada pela sua distribuição. A ausência total de saída normalmente significa que o kernel é anterior à opção; uname -r confirma isso. Algumas imagens de cloud minimalistas não incluem o ficheiro /boot/config-*. Nesse caso, leia zcat /proc/config.gz, que só funciona quando o kernel foi compilado com CONFIG_IKCONFIG_PROC.

A linha ls mostra os parâmetros llc_* quando a funcionalidade está compilada no kernel. Se não mostrar nada enquanto CONFIG_SCHED_CACHE=y, monte primeiro o debugfs com sudo mount -t debugfs none /sys/kernel/debug.

Para comparar a sua carga de trabalho com a funcionalidade ativada e desativada, registe primeiro o valor atual, porque terá de o repor:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

Execute o benchmark, escreva novamente o valor que registou e execute-o outra vez. As alterações feitas no debugfs não persistem após um reboot. Isso é o comportamento pretendido durante os testes.

Quando uma distribuição disponibiliza um kernel 7.2

O mainline não é o kernel com que o seu VPS arranca. A versão em uname -r veio da sua distribuição, e cada distribuição tem o seu próprio percurso entre uma versão mainline e o servidor.

A Fedora faz rebase das versões estáveis para kernels mainline mais recentes durante o período de suporte. Por isso, na Fedora, sudo dnf upgrade --refresh seguido de um reboot é todo o processo. Normalmente, é o primeiro lugar onde um tenant pode experimentar um kernel novo. Esse ritmo faz parte do que escolhe quando executa Fedora Server num VPS.

A Ubuntu disponibiliza um kernel novo em cada versão semestral e depois leva-o para a versão anterior de suporte de longo prazo (LTS) através da stack HWE (hardware enablement). Em agosto de 2026, o Ubuntu 24.04 LTS ainda instala o 6.8, de abril de 2024, como kernel GA, enquanto a sua stack HWE passou para o 6.14 em agosto de 2025 e para o 6.17 em fevereiro de 2026. Esta é a escala de tempo realista: uma versão mainline de agosto de 2026 chega a uma stack HWE LTS cerca de um ano depois.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

A Debian stable mantém um kernel durante todo o ciclo de vida da versão e disponibiliza kernels mais recentes através de backports, que ativa por pacote:

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

Depois de qualquer uma destas opções, faça reboot e confirme com uname -r e o grep acima. Um kernel novo não pode ser carregado em execução: live kernel patching num VPS substitui o código de funções individuais no kernel em execução, mas não pode alterar layouts de estruturas nem adicionar ficheiros debugfs. O agendamento sensível à cache faz ambas as coisas, porque adiciona campos a mm_struct. Por isso, só fica disponível ao arrancar um kernel novo.

Há duas tarefas práticas adicionais. Mantenha o kernel antigo arrancável até o novo ter suportado a sua carga durante algum tempo. É para isso que serve fixar o kernel que arranca num VPS. Monitorize também /boot, porque a partição de boot de um VPS pequeno fica cheia depois de algumas atualizações do kernel, conforme explicado em remover kernels antigos no Ubuntu.

Falta uma questão prática sobre a responsabilidade. Num VPS KVM, o kernel guest é seu: escolhe-o, arranca-o e pode fazer rollback. O kernel host pertence ao seu fornecedor, e nenhuma definição dentro do guest altera o scheduler executado pelo hypervisor. Por isso, uma nota de release sobre a colocação de tarefas no scheduler conta apenas metade da história para um tenant. A metade que controla é o lado guest.

Fontes utilizadas nesta página

• O resumo das alterações da versão 7.2 em kernelnewbies.org, para a data de lançamento de 16 de agosto de 2026 e as alterações que não estão relacionadas com o escalonador.
• A cobertura da LWN sobre a série de escalonamento com conhecimento da cache em lwn.net/Articles/1041668 e lwn.net/Articles/1058288, para os parâmetros ajustáveis do debugfs, o mecanismo de preferência por processo e os valores de benchmark reportados.
• O patch que condiciona a funcionalidade à topologia, "sched/cache: Introduce sched_cache_present", para a regra de que o balanceamento de carga com conhecimento da cache requer mais de um LLC num nó NUMA.

Para a versão anterior, consulte o que mudou no kernel Linux 7.1. Para saber como se chegou aos números de versão, consulte a linha do tempo da história do kernel Linux.

FAQ

O agendamento ciente da cache no Linux 7.2 torna um VPS mais rápido?

Normalmente, não por si só. A funcionalidade só é ativada quando um nó NUMA comunica mais de uma cache de último nível, e um guest KVM típico não expõe esse esquema. Por isso, o código nunca é executado. Quando é executado, o guest continua a ser agendado duas vezes: o seu kernel escolhe uma vCPU, e o kernel do host decide em que núcleo físico essa thread da vCPU corre. Assim, uma decisão de cache tomada no guest pode ser anulada pelo host. Execute cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u no seu guest. Uma única linha que abranja todas as vCPUs significa que não há nada para a funcionalidade organizar.

Como verifico se o meu kernel tem CONFIG_SCHED_CACHE?

Execute grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y significa que a funcionalidade está incluída no kernel, # CONFIG_SCHED_CACHE is not set significa que a sua distribuição a desativou, e nenhuma saída significa que o kernel é anterior à opção. Se a imagem não tiver o ficheiro /boot/config-*, experimente zcat /proc/config.gz, que só existe em kernels compilados com CONFIG_IKCONFIG_PROC. Pode confirmar o estado em runtime com sudo ls /sys/kernel/debug/sched/ | grep -i llc, que lista os parâmetros llc_* quando a funcionalidade está presente.

Como desativo o agendamento ciente da cache sem reiniciar?

Escreva 0 no parâmetro de tolerância: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Isto desativa a funcionalidade em runtime e permite alterná-la de forma controlada para um benchmark A/B. Leia primeiro o valor atual com sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance e volte a escrevê-lo depois, porque os valores predefinidos variam entre builds. Nada do que for escrito em debugfs sobrevive a um reboot. Se cat comunicar No such file or directory, o seu kernel não tem a funcionalidade compilada e não há nada para desativar.

Quando é que Ubuntu ou Debian vão disponibilizar um kernel baseado no 7.2?

A Fedora faz rebase das versões estáveis para kernels mainline novos. Por isso, a versão chega primeiro através de um dnf upgrade normal e de um reboot. O Ubuntu disponibiliza kernels novos em cada versão lançada a cada seis meses e fornece-os também para a versão LTS anterior através da stack HWE. Historicamente, a diferença aproxima-se de um ano: em agosto de 2026, a stack HWE do 24.04 LTS está no 6.17, lançado em fevereiro de 2026, enquanto o seu kernel GA continua no 6.8. O Debian stable mantém um kernel durante todo o ciclo da versão e disponibiliza versões mais recentes através de trixie-backports, que instala por pacote com apt install -t trixie-backports linux-image-amd64.