DEV Community: Alex Volnei Galante

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte VIII

Alex Volnei Galante — Fri, 21 Aug 2026 01:03:13 +0000

[!NOTE]
Última encerramento da "saga" de gerenciamento de memória. Na Parte VII vimos reclaim, PSI e o OOM Killer. Agora fechamos com o mecanismo que amarra tudo em produção — os cgroups v2 — e a conexão profunda com Python, .NET e Go, diagnóstico e estudos de caso.

Sumário

Memory Control Groups (cgroups v2)
- memory.max, memory.high e memory.low
- Memory accounting
- Hierarquia e eventos
Conexão com Backend: Python
Conexão com Backend: .NET
Conexão com Backend: Go
Técnicas de Diagnóstico e Tuning
Boas Práticas
Estudos de Caso
Encerramento da Série de Memória
Referências Bibliográficas

Memory Control Groups (cgroups v2)

Na Parte V falamos de alocação global vs local de frames. Os cgroups (control groups) são como o Linux moderno reintroduz fronteiras locais sobre um sistema global — e são a fundação de todo container (Docker, Podman, Kubernetes). Todo pod que você sobe é, no fundo, um conjunto de processos dentro de um cgroup com limites de memória.

Vamos focar em cgroups v2 (a versão unificada, padrão nas distros modernas). O controlador de memória expõe arquivos num diretório do sistema de arquivos cgroup:

# Um container/serviço vive em algo como:
/sys/fs/cgroup/system.slice/docker-<id>.scope/
# ou, no Kubernetes:
/sys/fs/cgroup/kubepods.slice/.../<pod>/

memory.max, memory.high e memory.low

Os três controles essenciais, e a diferença entre eles é crucial e frequentemente ignorada:

     0 ─────────── memory.low ─────── memory.high ─────── memory.max
     │                  │                   │                  │
  protegido do    abaixo daqui,        throttle:          limite HARD:
  reclaim         reclaim "poupa"      reclaim agressivo   estourou → OOM
                  este cgroup          + throttle da app   do cgroup

memory.max — o limite absoluto (hard limit). Se o cgroup tenta passar disso e o reclaim não consegue segurar, o OOM Killer do cgroup dispara (o OOMKilled do Kubernetes). É o teto intransponível.
memory.high — o limite suave (throttle). Ao ultrapassá-lo, o cgroup não é morto; em vez disso, o kernel aplica reclaim agressivo e desacelera (throttle) as alocações do grupo, criando "contrapressão". É um freio, não uma guilhotina — dá à aplicação a chance de reagir (rodar GC, liberar cache) antes de bater no max.
memory.low — proteção. Memória abaixo desse valor é protegida do reclaim enquanto houver memória recuperável em outros cgroups. Garante um mínimo para serviços críticos.

# Ler os limites de um cgroup
cat /sys/fs/cgroup/<meu-servico>/memory.max     # ex.: 2147483648 (2 GB) ou "max"
cat /sys/fs/cgroup/<meu-servico>/memory.high    # ex.: 1932735283 (~1.8 GB)

# Definir (normalmente feito pelo Docker/K8s, mas você pode ajustar)
echo 2G > /sys/fs/cgroup/<meu-servico>/memory.max

[!IMPORTANT]
A estratégia de ouro em produção: configure memory.high abaixo de memory.max. O high dá à sua aplicação uma zona de "amortecimento" onde ela é desacelerada e pressionada a liberar memória (o runtime faz GC), antes de o max disparar um OOMKill abrupto. Muitos setups só definem max (via limits do K8s) e perdem essa rede de segurança.

Memory accounting

O cgroup contabiliza tudo: não só a memória anônima (heap) do processo, mas também o page cache e o slab atribuíveis a ele. Isso é uma surpresa comum:

cat /sys/fs/cgroup/<meu-servico>/memory.current   # uso total atual
cat /sys/fs/cgroup/<meu-servico>/memory.stat
# anon           524288000    ← heap/stack (páginas anônimas)
# file           838860800    ← PAGE CACHE contabilizado no cgroup!
# kernel_stack     2097152
# slab            10485760    ← estruturas do kernel deste cgroup
# sock             1048576
# ...

Pegadinha clássica: seu container "usa" memória perto do limite, mas boa parte é page cache (arquivos que ele leu). Isso normalmente é reclaimável e não causa OOM sozinho — mas conta no memory.current. Entender memory.stat (separando anon de file) é o que distingue um falso alarme de um vazamento real.

Hierarquia e eventos

Cgroups são hierárquicos: limites do pai restringem os filhos, e o accounting sobe na árvore. E, como vimos na Parte VII, o memory.events e o memory.pressure (PSI por cgroup) dão observabilidade fina:

cat /sys/fs/cgroup/<meu-servico>/memory.events
# high 152   ← bateu no throttle 152 vezes (sinal de subdimensionamento!)
# max  8
# oom  2
# oom_kill 2

cat /sys/fs/cgroup/<meu-servico>/memory.pressure   # PSI local (Parte VII)

Um high alto e crescente é o alarme precoce de que o container está apertado — muito antes do oom_kill. É a métrica que você quer no dashboard.

Conexão com Backend: Python

Python data-intensive (Pandas, NumPy, PyArrow) vive e morre pela relação com o page cache (Parte VI) e pelos limites de cgroup.

Page cache e mmap em análise de dados

Bibliotecas como Pandas e PyArrow podem ler arquivos via mmap, deixando o page cache fazer o trabalho pesado: só as páginas realmente tocadas entram na RAM, e são compartilhadas entre processos.

import pyarrow.parquet as pq

# memory_map=True → usa mmap; os dados vêm do page cache sob demanda,
# sem carregar o arquivo inteiro na heap do Python (zero-copy quando possível).
tabela = pq.read_table("dados_grandes.parquet", memory_map=True)

ETL sem entupir o page cache

Em jobs ETL que varrem arquivos gigantes uma única vez, o page cache vira um problema: ele enche a RAM com dados que não serão relidos, pressionando o working set de outros processos (o cenário de "varredura única" da Parte VII). A solução é a dica fadvise da Parte VI:

import os

def processar_arquivo_grande(caminho):
    fd = os.open(caminho, os.O_RDONLY)
    os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_SEQUENTIAL)  # read-ahead agressivo
    try:
        # ... lê e processa em streaming, sem carregar tudo ...
        pass
    finally:
        # Descarta do page cache o que já foi processado: não polui a RAM
        os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_DONTNEED)
        os.close(fd)

Evitando OOM em scripts de dados e isolando Celery

Um script Pandas que faz df.copy() descuidado dobra o uso de memória e toma OOM (Parte VII). Monitore com tracemalloc (Artigo 2, Parte IV) e processe em chunks. Para workers Celery, isole cada um em seu cgroup com memory.high/memory.max, evitando que um worker guloso derrube os vizinhos:

# systemd unit de um worker Celery
[Service]
MemoryHigh=1500M      # throttle: pressiona antes do limite
MemoryMax=2G          # hard limit: OOM do cgroup aqui

Conexão com Backend: .NET

FileStream, page cache e MemoryMappedFile

Por padrão, System.IO.FileStream usa I/O bufferizado — passa pelo page cache (Parte VI). Para arquivos grandes acessados aleatoriamente, MemoryMappedFile deixa o kernel gerenciar via page faults:

using System.IO.MemoryMappedFiles;

using var mmf = MemoryMappedFile.CreateFromFile("dados_grandes.bin",
                                                FileMode.Open);
using var accessor = mmf.CreateViewAccessor();
// O acesso dispara page faults que trazem só as páginas necessárias
// do page cache — sem carregar o arquivo inteiro na managed heap.
byte valor = accessor.ReadByte(offset);

GC pressure vs kernel memory pressure

Um ponto sutil: o GC do .NET decide coletar com base na sua própria visão de heap, que pode não enxergar a pressão de memória do cgroup. O resultado: o container bate em memory.high/memory.max (Parte VII) antes de o GC achar que precisa coletar → throttle ou OOMKill. A ponte é fazer o CLR respeitar o cgroup:

// runtimeconfig.json
{
  "configProperties": {
    "System.GC.Server": true,
    "System.GC.HeapHardLimitPercent": 75   // GC "vê" o limite do container
  }
}

Assim o GC coleta de forma mais agressiva conforme se aproxima do teto, transformando um OOMKill em coleta controlada. (Retomamos aqui o tema do Server GC da Parte IV.)

Diagnóstico e page cache

dotnet-counters monitor -p <PID> --counters System.Runtime
#   GC Heap Size, Gen 2 GC Count, LOH Size, Working Set...

# Correlacionar working set do processo com o page cache do cgroup
cat /sys/fs/cgroup/<container>/memory.stat | grep -E 'anon|file'

Conexão com Backend: Go

mmap e I/O com page cache

Go acessa mmap diretamente via syscall.Mmap, ideal para processar arquivos grandes (log aggregation, índices) aproveitando o page cache:

import (
    "os"
    "syscall"
)

func mapearArquivo(caminho string) ([]byte, error) {
    f, err := os.Open(caminho)
    if err != nil {
        return nil, err
    }
    defer f.Close()

    info, _ := f.Stat()
    // Mapeia o arquivo: o kernel serve as páginas via page cache,
    // sob demanda, sem cópia para a heap gerenciada pelo GC.
    return syscall.Mmap(int(f.Fd()), 0, int(info.Size()),
        syscall.PROT_READ, syscall.MAP_SHARED)
}

bufio e a interação com o page cache

bufio.Reader/bufio.Writer adicionam um buffer em user space sobre o I/O que já passa pelo page cache em kernel space. Para leituras sequenciais, isso reduz o número de syscalls (cada read traz um bloco maior), enquanto o read-ahead do kernel (Parte VI) trabalha por baixo. Duas camadas de buffer cooperando.

GOMEMLIMIT: o freio contra o OOM do cgroup

O ponto mais importante para Go em containers. Como o GC do Go (por padrão, guiado por GOGC) não conhecia o limite do cgroup, apps Go tomavam OOMKill sob picos. O GOMEMLIMIT (Go 1.19+) resolve: define um teto suave de memória que faz o GC ficar mais agressivo ao se aproximar dele.

# Alinhe o GOMEMLIMIT ABAIXO do memory.max do cgroup (deixe folga p/ não-heap)
GOMEMLIMIT=1800MiB ./minha-app     # se o container tem memory.max=2Gi

Isso é o equivalente Go do HeapHardLimitPercent do .NET: fazer o runtime "enxergar" o cgroup (Parte VII) e agir antes do OOM.

Direct I/O

Para workloads que gerenciam o próprio cache e não querem duplicação no page cache (Parte VI), Go pode abrir arquivos com O_DIRECT — casos específicos (bancos, storage engines), com o custo de alinhamento de buffers e perda de read-ahead automático.

Técnicas de Diagnóstico e Tuning

O arsenal completo do Artigo 3, conectando todas as partes:

# 1. Visão geral (lembre: 'available', não 'free' — Parte VI)
free -h
grep -E 'MemAvailable|Cached|Dirty|Writeback|SReclaimable' /proc/meminfo

# 2. Pressão real de memória (PSI — Parte VII). A métrica que importa.
cat /proc/pressure/memory
cat /sys/fs/cgroup/<servico>/memory.pressure

# 3. Slab: memória do kernel (Parte VI)
sudo slabtop -o
grep -E 'SReclaimable|SUnreclaim' /proc/meminfo

# 4. cgroup: o que realmente está acontecendo no container (Parte VIII)
cat /sys/fs/cgroup/<servico>/memory.current
cat /sys/fs/cgroup/<servico>/memory.stat      # separe anon (heap) de file (cache)
cat /sys/fs/cgroup/<servico>/memory.events    # high/oom_kill

# 5. Swap e reclaim (Partes III e VII)
vmstat 1                                       # si/so + coluna 'wa'
sar -B 1                                       # pgscank/pgscand (kswapd vs direct)

# 6. Watermarks e zonas (Parte VII)
cat /proc/zoneinfo | grep -E 'zone|min|low|high|free'

# 7. Quem foi morto pelo OOM (Parte VII)
journalctl -k | grep -i 'out of memory'

Tuning que vale conhecer

vm.swappiness            # anon-swap vs cache-drop (Parte VII)
vm.min_free_kbytes       # folga da watermark min (Parte VII)
vm.dirty_ratio           # teto de dirty pages antes de bloquear (Parte VI)
vm.dirty_background_ratio# quando as flusher threads acordam (Parte VI)

Boas Práticas

Configure memory.high abaixo de memory.max. Dê à aplicação uma zona de amortecimento com throttle antes do OOMKill. Só definir limits no K8s não basta.
Faça o runtime enxergar o cgroup. GOMEMLIMIT (Go), HeapHardLimitPercent (.NET), max_requests/monitoramento (Python). O runtime deve fazer GC/reciclagem antes do memory.max.
Monitore por PSI, não por free. Alerte em memory.pressure (full avg60) e em memory.events:high, que sobem antes do OOM. Considere systemd-oomd para ação graciosa.
Entenda seu accounting. Separe anon de file no memory.stat. Cache alto raramente é problema; anon crescente sem parar é vazamento.
Use dicas de page cache em jobs de varredura única. POSIX_FADV_DONTNEED/SEQUENTIAL em ETL para não expulsar o working set alheio.
Direct I/O só quando fizer sentido. Se a aplicação já tem cache próprio (bancos), O_DIRECT evita dupla cache; caso contrário, o page cache é seu amigo.

Estudos de Caso

1. Python — Pipeline de ETL com controle de page cache

Um job noturno de ETL em Pandas processava dezenas de arquivos Parquet de vários GB. A cada execução, o page cache enchia com dados de uso único, pressionando os serviços co-residentes (que começavam a sofrer direct reclaim — Parte VII). A solução combinou leitura em chunks, memory_map=True no PyArrow e POSIX_FADV_DONTNEED após cada arquivo. Resultado: o working set dos serviços vizinhos deixou de ser expulso, e o PSI full do host caiu drasticamente.

2. .NET — Microserviço com memory.high para prevenir OOM

Uma API ASP.NET Core em Kubernetes sofria OOMKilled intermitente sob picos. Só havia limits.memory (= memory.max) definido; sem memory.high, o container ia de "confortável" a "morto" sem transição. A correção: adicionar memory.high a ~85% do max, configurar HeapHardLimitPercent=75 e alertar em memory.events:high. O Server GC passou a coletar sob pressão, o throttle absorveu os picos, e os OOMKills cessaram.

3. Go — Stream processor com mmap e GOMEMLIMIT

Um agregador de logs em Go mapeava arquivos grandes via syscall.Mmap e sofria OOMKill quando o volume subia — o GC, guiado só por GOGC, não via o limite do container. Definir GOMEMLIMIT logo abaixo do memory.max fez o GC intensificar perto do teto; combinado ao mmap (que mantém os dados no page cache, fora da heap gerenciada), o RSS anônimo estabilizou e o OOM desapareceu.

Encerramento da Série de Memória

Percorremos um caminho longo. No Artigo Sobre Gerenciamento de Memória, construímos a fundação: a hierarquia de memória, a abstração do espaço de endereçamento, paginação, tabelas multinível, TLB, page faults, Copy-on-Write, o memory layout de um processo, NUMA — e como CPython, CLR e o runtime Go se apoiam em tudo isso.

O próximo artigo da série muda de subsistema: I/O e Armazenamento — block layer, I/O schedulers, filesystems e o revolucionário io_uring. Muitos dos conceitos daqui (page cache, dirty pages, fsync, Direct I/O) reaparecerão lá, agora do ponto de vista do disco. Até lá! tenham paciencia que esse vai demorar um pouco mais pra sair, mas vai ser tão profundo quanto este.

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte VII

Alex Volnei Galante — Fri, 21 Aug 2026 00:55:52 +0000

Se voce chegou ate aqui meus parabens, gerenciamento de memoria e kernel linux nao sao assuntos triviais. Nesta parte vamos finalmente falar de reclaim e OOM — como o kernel decide quando e como recuperar memoria, e o que acontece quando ele nao consegue.

Sumário

Watermarks: os níveis de alerta
kswapd: o reclaim em background
Direct reclaim: quando não dá para esperar
As LRU lists do Linux
vm.swappiness
PSI: Pressure Stall Information
O OOM Killer
- Como a vítima é escolhida
- Ajustando o oom_score_adj
- OOM em cgroups
Referências Bibliográficas

Watermarks: os níveis de alerta

Na Parte IV mencionamos que cada zona de memória tem watermarks (marcas d'água). Agora elas entram em ação. O kernel monitora a memória livre de cada zona contra três limiares:

Memória livre na zona
    alta │──────────────────────  WATERMARK_HIGH  ← "tudo ok, pare de recuperar"
         │
         │──────────────────────  WATERMARK_LOW   ← "acorde o kswapd!"
         │
   baixa │──────────────────────  WATERMARK_MIN   ← "emergência: direct reclaim"
         │
       0 └──────────────────────  abaixo do min → risco de OOM

Acima de high: memória confortável, nada a fazer.
Cruzou low (descendo): o kernel acorda o kswapd para recuperar memória em background.
Cruzou min: situação crítica — a alocação força direct reclaim (a própria thread que pede memória precisa recuperá-la antes de prosseguir).

# Ver as watermarks de cada zona (em páginas)
cat /proc/zoneinfo | grep -E 'Node|zone|min|low|high|free'

# vm.min_free_kbytes controla o WATERMARK_MIN; aumentá-lo dá mais "folga"
# ao kernel (útil em máquinas com rajadas de alocação), ao custo de RAM reservada.
sysctl vm.min_free_kbytes

kswapd: o reclaim em background

O kswapd é uma thread de kernel (uma por nó NUMA) cuja função é recuperar memória proativamente, antes que falte. Quando a memória livre cai abaixo da watermark low, o kswapd acorda e começa a liberar páginas até voltar acima da watermark high.

O que ele recupera, em ordem de preferência:

Páginas de page cache limpas (file-backed, não modificadas) — as mais baratas: basta descartar (Parte VI).
Páginas de page cache sujas — precisam de write-back antes.
Páginas anônimas — precisam ir para o swap (se houver).
Slab reclaimable — via shrinkers (Parte VI).

Como o kswapd trabalha em background, idealmente ele mantém a memória saudável sem que as aplicações percebam. Um kswapd trabalhando muito (visível como consumo de CPU dele em top) é sinal de pressão de memória sustentada.

Direct reclaim: quando não dá para esperar

Se a alocação de memória é tão rápida que o kswapd não consegue acompanhar, e a memória livre bate na watermark min, o kernel recorre ao direct reclaim: a própria thread da aplicação que pediu memória é forçada a parar e recuperar páginas ela mesma, ali, sincronamente, antes de a alocação retornar.

Isso é péssimo para latência. Do ponto de vista da sua aplicação, uma alocação trivial (malloc, criar um objeto) de repente trava por milissegundos ou mais, enquanto a thread faz o trabalho sujo de liberar memória — possivelmente esperando I/O de swap ou write-back.

Alocação normal:      app pede memória → kernel entrega → segue (µs)
Direct reclaim:       app pede memória → SEM frames livres →
                      app é sequestrada para liberar páginas →
                      espera write-back/swap → só então recebe (ms+)

Picos de latência de cauda (p99) inexplicáveis em produção são, com frequência, direct reclaim acontecendo. A métrica PSI (adiante) foi criada justamente para tornar isso visível.

As LRU lists do Linux

Como o kernel decide quais páginas recuperar? Aqui a teoria da Parte V vira prática. O Linux mantém, por nó/zona (e por cgroup), um conjunto de listas LRU:

                 ┌─────────────────┐
   file-backed:  │  active_file    │  páginas de arquivo "quentes"
                 ├─────────────────┤
                 │  inactive_file  │  candidatas a despejo (frias)
                 └─────────────────┘
                 ┌─────────────────┐
   anônimas:     │  active_anon    │  heap/stack "quentes"
                 ├─────────────────┤
                 │  inactive_anon  │  candidatas a swap
                 └─────────────────┘

Páginas nascem na lista inactive. Se forem referenciadas de novo (o bit Accessed, Parte II), são promovidas para active. Sob pressão, o kernel recupera da ponta da lista inactive — as páginas frias — mantendo as active. É o algoritmo do relógio / LRU aproximado da Parte V, refinado (e agora, com MGLRU, ainda mais preciso — Parte VI).

A separação file vs anon é deliberada: recuperar uma página de arquivo limpa é barato (só descartar); recuperar uma anônima exige swap. O vm.swappiness controla o equilíbrio entre as duas.

Refault distance e proteção do working set

Um problema clássico do LRU simples: uma varredura única de muitos arquivos (um grep gigante, um backup) pode inundar o inactive_file e expulsar o working set real do cache. O Linux moderno rastreia a refault distance — se uma página descartada é logo pedida de volta (refault), o kernel aprende que ela era importante e protege o working set de ser expulso por acessos transitórios. É a formalização da Parte V ("proteger o working set") implementada de forma adaptativa.

vm.swappiness

O parâmetro mais famoso (e mais mal-entendido) do tuning de memória. O vm.swappiness (0 a 200; padrão geralmente 60) define o quanto o kernel prefere recuperar memória fazendo swap de páginas anônimas versus descartar page cache:

swappiness baixo (ex.: 10): "evite swap, prefira descartar cache". Bom quando o page cache é descartável e você quer manter a heap na RAM.
swappiness alto (ex.: 100): "não hesite em fazer swap de páginas anônimas frias". Pode liberar RAM para mais cache.

sysctl vm.swappiness
# Ajuste temporário:
sudo sysctl -w vm.swappiness=10

[!NOTE]
Não existe valor "correto" universal. Em bancos de dados que gerenciam o próprio cache, swappiness baixo costuma ajudar. Em servidores de arquivos, cache é rei. Em containers com memory.max, o comportamento muda (Parte VIII). E, com SSD/NVMe (Parte III), o swap não é mais o vilão que era nos tempos de HDD — swappiness moderado pode ser saudável.

PSI: Pressure Stall Information

Antes do PSI, medir pressão de memória era arte adivinhatória: free engana (Parte VI), e alta atividade de swap pode ser normal ou catastrófica. O PSI (Pressure Stall Information), introduzido no Kernel 4.20, mudou o jogo.

O PSI mede quanto tempo as tarefas ficaram paradas (stalled) esperando por um recurso — exatamente o que dói. Para memória:

cat /proc/pressure/memory
# some avg10=0.00 avg60=0.15 avg300=0.05 total=12345678
# full avg10=0.00 avg60=0.08 avg300=0.02 total=6789012

some: % do tempo em que pelo menos uma tarefa ficou parada esperando memória (reclaim, swap, refault).
full: % do tempo em que todas as tarefas não-ociosas ficaram paradas simultaneamente — o sistema inteiro travado por memória. full subindo é o sinal mais claro e precoce de thrashing (Parte V).

Diferente de olhar swap in/out cru, o PSI mede o impacto real na execução. É a métrica moderna para alertas: em vez de "swap > X", monitore "memory pressure full avg60 > Y%". Ferramentas como o systemd-oomd e o oomd do Facebook usam PSI para agir antes do OOM Killer clássico — matando algo de forma controlada quando a pressão passa de um limiar, evitando o congelamento total.

# Pressão de memória por cgroup (essencial em containers — Parte VIII)
cat /sys/fs/cgroup/<meu-servico>/memory.pressure

O famoso OOMKiller

Chegamos ao mais temido. Quando todo o reclaim falha — não há mais page cache para descartar, nem swap para páginas anônimas, e a memória continua insuficiente — o kernel toma a decisão nuclear: invocar o OOM Killer (Out-Of-Memory Killer) para matar um processo e liberar memória, evitando o congelamento total do sistema.

Lembra do overcommit (Parte III)? O kernel prometeu mais memória do que tem, apostando (via zero-fill on demand e COW) que nem todos escreveriam tudo. O OOM Killer é o que acontece quando essa aposta dá errado e todos cobram ao mesmo tempo.

Como a vítima é escolhida

O OOM Killer não escolhe ao acaso — ele tenta matar o processo que libera mais memória causando o menor dano. Cada processo tem um oom_score, derivado principalmente do seu consumo de memória (RSS + swap + page tables), ajustado por oom_score_adj:

# Score atual de um processo (0 a 1000; maior = mais provável de ser morto)
cat /proc/<PID>/oom_score

# O ajuste que você controla (-1000 a +1000)
cat /proc/<PID>/oom_score_adj

Grosso modo: quanto mais memória um processo usa, maior seu score, mais provável ser a vítima. Isso costuma acertar (o maior consumidor geralmente é o culpado), mas nem sempre — às vezes mata justamente seu processo principal, o maior da máquina.

Ajustando o oom_score_adj

Você pode influenciar a decisão. O oom_score_adj vai de -1000 (nunca mate, imune) a +1000 (mate primeiro):

# Proteger um processo crítico (ex.: o banco de dados) de ser morto
echo -900 > /proc/<PID_do_banco>/oom_score_adj

# Marcar um processo "sacrificável" (ex.: um cache reconstruível) para morrer primeiro
echo 800 > /proc/<PID_do_cache>/oom_score_adj

Isso é útil para proteger o processo essencial e direcionar o OOM Killer a matar algo reconstruível. Quando o OOM dispara, o kernel registra tudo no log:

dmesg | grep -i 'killed process'
# Out of memory: Killed process 12345 (python) total-vm:8000000kB,
#   anon-rss:7500000kB, file-rss:0kB, ... score 850
journalctl -k | grep -i oom

OOM em cgroups

Em containers, o OOM mais comum não é o global — é o OOM do cgroup, disparado quando o grupo estoura seu memory.max (Parte VIII). O kernel mata um processo dentro daquele cgroup, sem afetar o resto do host. É o clássico "meu pod reiniciou com OOMKilled no Kubernetes":

# Contadores de eventos de OOM do cgroup
cat /sys/fs/cgroup/<meu-pod>/memory.events
# low 0
# high 152      ← quantas vezes bateu memory.high (throttling)
# max 8         ← quantas vezes bateu memory.max
# oom 2         ← quantas vezes o OOM do cgroup disparou
# oom_kill 2    ← quantos processos foram mortos

Kernels 5.x melhoraram o OOM Killer para evitar thrashing prolongado: em vez de deixar o sistema agonizar minutos perto do limite (tudo em reclaim, nada progredindo), ele age mais decisivamente. E, com PSI + systemd-oomd/oomd, é possível agir em user space antes do OOM do kernel, matando de forma mais graciosa e previsível.

[!TIP]
No Kubernetes, defina requests e limits de memória conscientemente e configure GOMEMLIMIT (Go), HeapHardLimitPercent (.NET) ou reciclagem de workers (Python) abaixo do memory.max. Assim seu runtime faz GC/limpeza antes de o cgroup estourar, transformando um OOMKill abrupto numa degradação controlada. Detalhamos isso na Parte VIII.

Continua na Parte VIII — a última do Artigo 3 —, onde amarramos toda a teoria de controle de memória com os cgroups v2 (memory.max/high/low, accounting, memory.pressure) e mergulhamos na conexão com Python, .NET e Go: page cache em ETL, MemoryMappedFile, mmap em Go, tuning de containers, diagnóstico e estudos de caso reais.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte VI

Alex Volnei Galante — Fri, 21 Aug 2026 00:54:32 +0000

Uffaaa cansativo não? bem eu quiz trazer com bastante profundidade o tema pra dar a devida imersão, só os fortes sobrevivem kkkkk.

Sumário

Princípios de cache e buffering
O Page Cache
- "Free memory is wasted memory"
- Read-ahead: leitura especulativa
- Write-back: escritas atrasadas e dirty pages
- Multi-Generational LRU (MGLRU)
- Buffered I/O vs Direct I/O
- madvise e fadvise: dando dicas ao kernel
O Slab Allocator
- O buddy system: a base
- Por que slab? O problema dos objetos pequenos
- SLUB vs SLAB vs SLOB
- Shrinkers
Referências Bibliográficas

Princípios de cache e buffering

Antes do page cache do Linux, vale relembrar os princípios de cache que Tanenbaum apresenta — porque o page cache é uma aplicação direta deles:

Cache hit vs miss: o dado buscado está no cache (hit, rápido) ou precisa vir da fonte lenta (miss).
Write-through: toda escrita vai imediatamente para a camada lenta (disco). Seguro, mas lento.
Write-back: escritas ficam no cache e são gravadas no disco mais tarde, em lote. Rápido, mas há uma janela de risco (dados na RAM ainda não persistidos).
Read-ahead (prefetching): trazer dados antes de serem pedidos, apostando na localidade espacial.

Historicamente, o Unix tinha dois caches separados: o buffer cache (para blocos do disco) e o page cache (para páginas de arquivos mapeados). Isso causava duplicação e incoerência. Desde o Kernel 2.4, o Linux os unificou: hoje há um único page cache que serve tanto o I/O de arquivos quanto o mapeamento de memória.

O Page Cache

O page cache é a estrutura que guarda, na RAM, páginas de arquivos que foram lidos ou escritos. É, provavelmente, o mecanismo com maior impacto na performance de I/O de qualquer aplicação backend — e o mais mal compreendido.

Quando sua aplicação lê um arquivo:

1ª leitura de arquivo.dat:
  read() → page cache MISS → busca no disco (lento, major cost) →
           copia para o page cache → entrega à aplicação

2ª leitura do MESMO arquivo (por qualquer processo!):
  read() → page cache HIT → entrega direto da RAM (nanossegundos)
           SEM tocar o disco

O page cache é compartilhado por todo o sistema. Se o processo A lê um arquivo e o processo B lê o mesmo arquivo depois, B aproveita o cache aquecido por A. É por isso que a segunda execução de um teste, um build, ou uma query que lê os mesmos arquivos é sempre mais rápida.

"Free memory is wasted memory"

Aqui está a fonte de confusão número um de quem administra servidores Linux. Você roda free -h e vê:

              total   usado   livre   compart.  buff/cache  disponível
Mem:          15Gi    3Gi     500Mi   200Mi     11Gi        11Gi

"Só 500 MB livres?! Vou tomar OOM!" — não. Aqueles 11 GB em buff/cache são page cache: cópias de arquivos que o kernel manteve na RAM porque a memória estava ociosa. Essa memória é disponível (coluna disponível/available): no instante em que a aplicação precisar, o kernel descarta o cache limpo e entrega os frames. É por isso que a coluna que importa é a available, não a free.

A filosofia do Linux é: memória livre é memória desperdiçada. RAM parada não ajuda ninguém; melhor usá-la como cache e liberá-la sob demanda. Um servidor "saudável" com uptime longo naturalmente tem quase toda a RAM em page cache.

# A coluna que realmente importa é 'available'
free -h

# Detalhe do page cache no /proc/meminfo
grep -E 'Cached|Buffers|Dirty|Writeback' /proc/meminfo
# Cached:        11534336 kB   ← page cache
# Dirty:            45000 kB   ← modificado, ainda não gravado no disco
# Writeback:            0 kB   ← sendo gravado agora

Read-ahead: leitura especulativa

Quando o kernel detecta um padrão de leitura sequencial, ele antecipa: em vez de trazer só a página pedida, traz também as próximas para o page cache, apostando que serão lidas em breve (localidade espacial em ação). Quando o pedido chega, a página já está lá.

# Ver/ajustar o tamanho do read-ahead de um dispositivo (em KB)
cat /sys/block/nvme0n1/queue/read_ahead_kb   # ex.: 128

# Leituras sequenciais grandes (ETL, backup, scan de tabela) se beneficiam
# de read-ahead maior; acesso aleatório (banco OLTP) prefere valores menores.

Write-back: escritas atrasadas e dirty pages

Quando você escreve num arquivo, o dado não vai imediatamente ao disco. Ele é marcado como dirty (página suja) no page cache, e um conjunto de threads do kernel (historicamente pdflush, hoje as flusher threads por dispositivo) grava as páginas sujas no disco assincronamente, mais tarde. Isso é write-back, e é o que torna write() tão rápido.

O trade-off é durabilidade: dados sujos vivem só na RAM até o flush. Um crash ou queda de energia nessa janela perde os dados. É por isso que bancos de dados chamam fsync() — para forçar a gravação imediata e garantir persistência (voltaremos a fsync no Artigo 4).

# Parâmetros que controlam o write-back
sysctl vm.dirty_ratio            # % de RAM suja que BLOQUEIA a aplicação escrevendo
sysctl vm.dirty_background_ratio # % de RAM suja que ACORDA as flusher threads
sysctl vm.dirty_expire_centisecs # idade máxima de uma página suja antes do flush

# Forçar flush de tudo agora
sync

[!WARNING]
Em servidores com muita RAM, dirty_ratio alto pode acumular gigabytes de dados sujos. Quando o flush finalmente dispara, ele satura o disco e causa picos de latência ("write storms"). Em workloads write-heavy, muitas vezes reduz-se dirty_ratio/dirty_background_ratio para suavizar a gravação.

Multi-Generational LRU (MGLRU)

Por décadas, o Linux usou um esquema de duas listas LRU (active/inactive) para decidir quais páginas do cache manter — uma aproximação do LRU que estudamos na Parte V. A partir do Kernel 6.1, chegou o MGLRU (Multi-Generational LRU), que organiza as páginas em múltiplas gerações por idade, aproximando o LRU real com muito mais precisão e menor custo de CPU.

O MGLRU melhora significativamente a decisão de reclaim sob pressão, reduzindo tanto o thrashing quanto o uso de CPU em varredura. Para backend, o ganho é transparente: sob pressão de memória, o kernel toma decisões melhores sobre o que manter em cache. Distros modernas o habilitam por padrão.

# Verificar se o MGLRU está habilitado
cat /sys/kernel/mm/lru_gen/enabled   # 0x0007 = habilitado

Buffered I/O vs Direct I/O

Buffered I/O (o padrão): passa pelo page cache. Ganha caching, read-ahead e write-back automáticos. É o que você quer 95% do tempo.
Direct I/O (O_DIRECT): contorna o page cache, transferindo direto entre o disco e o buffer da aplicação. Faz sentido quando a aplicação gerencia seu próprio cache (bancos de dados como Oracle/PostgreSQL com grande shared_buffers) e o page cache seria só duplicação desperdiçada — ou para não "poluir" o cache com dados que só serão lidos uma vez.

Buffered:  app ──▶ page cache ──▶ disco     (caching, mas dupla cópia)
Direct:    app ──────────────────▶ disco     (zero-copy, mas sem caching)

madvise e fadvise: dando dicas ao kernel

Você pode orientar o kernel sobre seu padrão de acesso, para ele otimizar o page cache:

madvise(MADV_SEQUENTIAL) — "vou ler sequencialmente" → read-ahead agressivo.
madvise(MADV_RANDOM) — "acesso aleatório" → desliga read-ahead (evita trazer páginas inúteis).
madvise(MADV_DONTNEED) — "não preciso mais disto" → libera as páginas.
posix_fadvise(POSIX_FADV_DONTNEED) — descarta do page cache um trecho de arquivo já processado (ótimo em ETL para não entupir o cache).
madvise(MADV_HUGEPAGE) — pede huge pages para aquela região (lembra da Parte II).

import os

fd = os.open("arquivo_grande.dat", os.O_RDONLY)
# "Vou ler isto sequencialmente, faça read-ahead agressivo"
os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_SEQUENTIAL)
# ... processa o arquivo ...
# "Já terminei, pode descartar do page cache" (não entope a RAM)
os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_DONTNEED)
os.close(fd)

Essas dicas serão centrais nos exemplos de ETL e processamento de arquivos da Parte VIII.

O Slab Allocator

Até agora falamos da memória das aplicações. Mas o próprio kernel precisa alocar memória constantemente para suas estruturas internas: task_struct (lembra do Artigo 1?), inodes, dentries, buffers de rede (sk_buff), descritores de arquivo. Como ele faz isso?

O buddy system: a base

Na camada mais baixa, o kernel gerencia memória física em potências de 2 de páginas (1, 2, 4, 8... frames), usando o buddy system. Quando precisa de um bloco, ele encontra o menor bloco disponível que sirva; se for grande demais, o divide pela metade (os dois "buddies"). Ao liberar, blocos buddy livres são fundidos de volta.

Pedido de 1 bloco (4 KB), só há um bloco de 16 KB livre:

  [       16 KB       ]
        │ split
  [  8 KB  ][  8 KB  ]
     │ split
  [4KB][4KB][  8 KB  ]
   ▲
   entrega este; os buddies ficam livres para futuras fusões

O buddy system combate a fragmentação externa (juntando buddies), mas sofre de fragmentação interna: pedir 5 KB obriga a alocar um bloco de 8 KB, desperdiçando 3 KB. E aqui está o problema: o kernel raramente precisa de páginas inteiras — ele precisa de milhares de objetos pequenos (uma task_struct tem alguns KB; um inode, centenas de bytes). Usar o buddy system direto para isso seria um desperdício gigantesco.

# Estado do buddy system (blocos livres por ordem/potência de 2)
cat /proc/buddyinfo

Por que slab? O problema dos objetos pequenos

O slab allocator (conceito originado no Solaris, por Jeff Bonwick) resolve isso com duas ideias:

Caching de objetos por tipo: mantém "caches" dedicados para cada tipo de objeto frequente (um cache de task_struct, um de inode, etc.). Cada cache pega páginas inteiras do buddy system (os "slabs") e as fatia em objetos daquele tamanho, sem desperdício.
Reaproveitamento com estado: objetos liberados não são destruídos — voltam ao cache já parcialmente inicializados, prontos para reuso. Alocar/liberar vira quase de graça: só pegar/devolver da lista livre do slab.

Cache slab de 'task_struct':

  ┌──────── slab (1+ páginas do buddy) ────────┐
  │ [obj][obj][obj][obj][obj][obj][obj][obj]   │
  │  usado livre usado livre livre usado ...   │
  └────────────────────────────────────────────┘
        │
   listas: slabs cheios / parciais / vazios

Isso dá dois ganhos enormes: elimina a fragmentação interna para objetos pequenos e melhora a localidade de cache (objetos do mesmo tipo ficam agrupados). O kmalloc do kernel é implementado sobre caches slab de tamanhos padronizados (kmalloc-8, kmalloc-16, kmalloc-32...).

# Ver todos os caches slab, uso e número de objetos
sudo cat /proc/slabinfo
# name            <active_objs> <num_objs> <objsize> ...
# task_struct           142        160       9088   ...
# dentry              45230      48300        192   ...
# inode_cache         30120      31000        600   ...

# Visão amigável e ordenada por consumo
sudo slabtop

SLUB vs SLAB vs SLOB

O Linux teve três implementações da ideia:

Implementação	Característica	Uso
SLAB	Original, com filas por CPU complexas. Bom em cache, mas com muito overhead de metadados.	Legado
SLUB	Simplificado, menos metadados, escala melhor em muitos cores, melhor para debugging.	Padrão atual
SLOB	Minimalista, para sistemas embarcados com pouquíssima RAM.	Removido em kernels recentes

O SLUB é o padrão em praticamente todas as distribuições modernas — mais simples, mais escalável em máquinas com muitos núcleos, e com melhores ferramentas de diagnóstico.

Shrinkers

Quando a memória fica escassa (Parte VII), o kernel precisa recuperar memória não só do page cache, mas também dos caches slab. Os shrinkers são callbacks que cada subsistema registra para liberar objetos recuperáveis sob pressão — por exemplo, o cache de dentry/inode (o slab reclaimable) pode encolher para devolver páginas.

# Slab reclaimable (pode ser recuperado sob pressão) vs unreclaimable
grep -E 'SReclaimable|SUnreclaim' /proc/meminfo

Isso conecta diretamente com a Parte VII: sob pressão de memória, o reclaim aciona os shrinkers para encolher slabs recuperáveis, junto com o descarte de page cache.

Debugging: poisoning e leak detection

O SLUB oferece ferramentas para caçar bugs de memória do kernel: poisoning (preenche objetos livres com um padrão conhecido, tipo 0x6b, para detectar use-after-free) e detecção de vazamentos. Úteis para quem escreve drivers/módulos, mas bom saber que existem quando você investiga um SUnreclaim que só cresce (um vazamento de slab no kernel).

Continua na Parte VII, onde juntamos tudo: como o kernel realmente recupera memória sob pressão (kswapd, direct reclaim, watermarks, LRU lists), a métrica moderna de PSI (Pressure Stall Information), e o processo que todo dev backend teme e precisa entender — o OOM Killer.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte V

Alex Volnei Galante — Fri, 21 Aug 2026 00:53:15 +0000

Chegamos à pergunta que os artigos passados deixaram no ar. Vimos que o kernel pode mover páginas "frias" para o swap quando a memória fica escassa. Mas como ele decide quais páginas são frias? Qual página remover quando você precisa de um frame livre e todos estão ocupados?

Essa é uma das perguntas mais estudadas em Sistemas Operacionais, e a resposta certa faz a diferença entre uma aplicação que voa e uma que passa a vida esperando o disco :D.

Vamos dos algoritmos teóricos (Tanenbaum) até o que o Linux realmente implementa, DISCLAIMER: Mano isso é muito nerdice mais eu adoro kkk

Sumário

O problema da substituição de páginas
Algoritmo Ótimo (OPT)
NRU: Not Recently Used
FIFO e a Anomalia de Belady
Segunda Chance e o Algoritmo do Relógio
LRU: Least Recently Used
O Modelo do Working Set
WSClock
Thrashing
Políticas de Alocação de Frames
Referências Bibliográficas

O problema da substituição de páginas

O cenário é o seguinte: a memória física está cheia, e ocorre um page fault que exige trazer uma nova página do disco. Não há frames livres. O kernel precisa escolher uma página vítima para despejar (evict), liberando um frame.

Se a página vítima estiver suja (dirty bit = 1, lembra da Parte II?), ela precisa ser gravada no disco antes de descartada. Se estiver limpa, pode ser simplesmente descartada (o conteúdo pode ser relido da origem). A escolha da vítima é crucial:

Se removermos uma página que será acessada logo em seguida, causamos um novo page fault imediato — desperdício.
Se removermos uma página que não será mais usada, acertamos em cheio.

O objetivo de todo algoritmo de substituição é, portanto, prever o futuro: remover a página que ficará mais tempo sem ser acessada. Como não temos bola de cristal, os algoritmos são aproximações dessa previsão.

Algoritmo Ótimo (OPT)

O algoritmo ótimo é simples de enunciar: remova a página que só será usada mais longe no futuro (ou nunca mais). Ele é comprovadamente ótimo — gera o menor número possível de page faults.

O problema? É impossível de implementar. Exigiria saber, no momento da decisão, todos os acessos futuros do programa. Ele só pode ser calculado a posteriori, rodando o programa uma vez, registrando os acessos, e então analisando.

Então por que estudá-lo? Porque ele é o baseline teórico. Ao avaliar um algoritmo real, comparamos seu número de faults com o do OPT: quanto mais próximo, melhor o algoritmo.

Referências: 7 0 1 2 0 3 0 4 2 3 0 3 2
3 frames. Quando precisa despejar, OPT olha o FUTURO:

Acesso ao '3' com frames [7,0,1] cheios:
  - 7 será usado? Não aparece mais → despeja o 7. ✔

NRU: Not Recently Used

O NRU é a primeira aproximação prática, e usa dois bits que já conhecemos da PTE (Parte II):

R (Referenced/Accessed): ligado pelo hardware quando a página é lida ou escrita.
M (Modified/Dirty): ligado pelo hardware quando a página é escrita.

Periodicamente (a cada tick de clock), o kernel zera o bit R de todas as páginas. Assim, R indica se a página foi acessada recentemente. Combinando R e M, formam-se 4 classes:

Classe 0: não referenciada, não modificada  (R=0, M=0) ← melhor vítima
Classe 1: não referenciada, modificada      (R=0, M=1)
Classe 2: referenciada, não modificada      (R=1, M=0)
Classe 3: referenciada, modificada          (R=1, M=1) ← pior vítima

O NRU remove uma página aleatória da classe não-vazia mais baixa. A intuição: prefira despejar páginas não usadas recentemente (R=0) e, entre elas, as limpas (M=0, que não precisam de write-back). Simples e razoável, ainda que grosseiro.

FIFO e a Anomalia de Belady

O FIFO (First-In, First-Out) é o mais ingênuo: mantém uma fila das páginas na ordem em que entraram e despeja a mais antiga.

O problema é óbvio: a página mais antiga pode ser justamente a mais usada (pense numa variável de configuração carregada no início e acessada o tempo todo). O FIFO a despejaria cegamente.

Mas o FIFO tem um defeito ainda mais bizarro e contraintuitivo: a Anomalia de Belady. Normalmente esperamos que mais frames de memória → menos page faults. Com o FIFO, em certas sequências de acesso, adicionar frames pode aumentar o número de page faults:

Sequência: 1 2 3 4 1 2 5 1 2 3 4 5

Com 3 frames: 9 page faults
Com 4 frames: 10 page faults  ← MAIS frames, MAIS faults! (anomalia)

Essa anomalia é o que motivou o estudo dos stack algorithms (algoritmos de pilha), como o LRU, que possuem a propriedade de inclusão: o conjunto de páginas com $n$ frames é sempre um subconjunto do conjunto com $n+1$ frames. Algoritmos de pilha nunca sofrem da Anomalia de Belady.

Segunda Chance e o Algoritmo do Relógio

O Segunda Chance é um FIFO esperto. Antes de despejar a página mais antiga, ele checa o bit R:

Se R = 0: a página não foi usada recentemente → despeja.
Se R = 1: dá uma "segunda chance" — zera o R, move a página para o fim da fila (como se tivesse acabado de chegar) e continua procurando.

Assim, páginas frequentemente usadas sobrevivem, enquanto páginas realmente antigas e não usadas são despejadas.

O Algoritmo do Relógio (Clock) é a implementação eficiente do Segunda Chance. Em vez de mover páginas numa fila (caro), organiza os frames num anel com um ponteiro (o "ponteiro do relógio"):

              ┌──────┐
         ┌───▶│ P0 R1│───┐
         │    └──────┘   │
    ┌──────┐         ┌──────┐
    │ P7 R0│         │ P1 R1│
    └──────┘         └──────┘
         ▲               │
         │    ┌──────┐   ▼
         └────│ P... │◀──┘
              └──────┘
                 ▲
              ponteiro

Ao precisar de vítima, o ponteiro avança:
  - R=1 → zera R e avança (segunda chance)
  - R=0 → despeja esta página, ponteiro para no próximo

O Clock é a base conceitual do que o Linux realmente usa (com refinamentos que veremos na Parte VII, nas LRU lists).

LRU: Least Recently Used

O LRU (Least Recently Used) parte de uma aposta poderosa: o passado recente é um bom preditor do futuro próximo. Ele despeja a página que há mais tempo não é acessada.

O LRU é excelente — muito próximo do ótimo na prática — mas caro de implementar exatamente. Manter a ordem exata de último acesso exigiria atualizar uma estrutura de dados a cada acesso à memória. Tanenbaum descreve as opções:

Com timestamps/contador: cada página guarda o "tempo" do último acesso. Despejar = achar o menor timestamp. Requer hardware que escreva o contador a cada acesso — caro.
Com matriz de bits: uma matriz $n \times n$ para $n$ frames, manipulada a cada referência. Inviável para muitos frames.

Por isso, sistemas reais usam LRU aproximado:

Aging (envelhecimento)

O algoritmo de aging aproxima o LRU com um contador por página. A cada tick, o kernel desloca o contador à direita e insere o bit R no topo:

Página A, ao longo de 5 ticks (bit R de cada tick à esquerda):
  tick 1 (R=1): 10000000
  tick 2 (R=0): 01000000
  tick 3 (R=1): 10100000
  tick 4 (R=0): 01010000
  tick 5 (R=0): 00101000

Página com MENOR valor de contador = usada há mais tempo = vítima.

O aging captura bem a noção de "recentemente usada" com custo baixo, e é a inspiração direta do mecanismo de LRU do Linux. Uma limitação: o contador tem tamanho finito, então ele "esquece" o histórico além de N ticks — mas na prática isso é suficiente.

O Modelo do Working Set

Os algoritmos acima decidem qual página despejar. Mas Peter Denning propôs uma pergunta mais profunda: quantas páginas um processo realmente precisa ter na memória para rodar bem?

O working set $W(t, \Delta)$ é o conjunto de páginas que um processo acessou nas últimas $\Delta$ unidades de tempo (ou referências). É a formalização do "conjunto de trabalho atual":

$$W(t, \Delta) = {\text{páginas referenciadas no intervalo } (t - \Delta,\ t)}$$

A ideia-chave: se mantivermos o working set inteiro de um processo na memória, ele terá pouquíssimos page faults, porque suas referências, pela localidade, caem quase todas dentro do working set. Se não conseguirmos manter o working set na memória, o processo sofre — muito.

O tamanho do working set varia conforme o programa muda de fase (inicialização, hot loop, shutdown). O parâmetro $\Delta$ (a janela) é um trade-off: muito pequeno perde páginas ainda úteis; muito grande retém páginas já frias.

Conexão backend: aquele exemplo da Parte I volta com força. Uma API pode ter 500 MB carregados, mas seu working set num dado segundo é talvez 50 MB. Dimensionar a RAM (ou o limite do container) abaixo do working set é a receita para thrashing.

WSClock

O WSClock combina o melhor de dois mundos: a eficiência do algoritmo do relógio com a inteligência do working set. É o algoritmo prático de referência em muitos sistemas.

Ele percorre os frames em anel (como o Clock), mas para cada página examina:

Para a página sob o ponteiro:
  - R = 1?  → zera R, atualiza "tempo do último uso", avança.
  - R = 0?  → calcula idade = tempo_atual - tempo_último_uso
      - idade ≤ Δ?  → está no working set, NÃO despeja, avança.
      - idade > Δ?  → fora do working set:
          - limpa?  → despeja (ótima vítima!)
          - suja?   → agenda write-back, avança (despeja na próxima volta)

O WSClock só despeja páginas que estão fora do working set (não usadas há mais que $\Delta$), respeitando a localidade e evitando despejar páginas que serão logo reusadas. É, em essência, a filosofia que o Linux persegue com suas LRU lists e o mecanismo de reclaim (Parte VII).

Thrashing

Quando o working set combinado de todos os processos excede a memória física disponível, acontece o pesadelo: thrashing.

No thrashing, o sistema passa mais tempo movendo páginas entre RAM e disco do que executando trabalho útil. Cada processo despeja páginas de que ainda precisa; ao acessá-las de novo, dispara major faults; para atendê-los, despeja páginas de outro processo, que também sofre — uma reação em cadeia:

CPU útil
  100% │────────╲
       │         ╲
       │          ╲          ← "penhasco" do thrashing
       │           ╲________________
     0%│                            
       └────────────────────────────▶ grau de multiprogramação
                    ▲
              ponto de thrashing: demanda de memória > capacidade

Como detectar: a assinatura clássica do thrashing é CPU baixa + I/O de disco (swap) altíssimo. A CPU está ociosa não por falta de trabalho, mas porque todo mundo está esperando o disco.

# Sinais de thrashing:
vmstat 1
#  r  b   swpd   free  ...  si   so   ...  us sy id wa
#  1 8  512000   2000      15000 18000     3  5  2 90
#             ▲                ▲    ▲                ▲
#    muito swap usado   swap in/out ALTOS    CPU 90% em I/O wait!

# A ferramenta moderna e muito mais precisa (PSI) veremos na Parte VII.

Prevenção: PFF (Page Fault Frequency)

Uma técnica de controle é o PFF (Page Fault Frequency): monitorar a taxa de page faults de cada processo e ajustar dinamicamente quantos frames ele recebe:

Taxa de faults acima de um limite superior → o processo precisa de mais frames.
Taxa abaixo de um limite inferior → o processo tem frames demais; pode ceder alguns.

Se não há frames suficientes para todos, o remédio drástico é suspender (fazer swap-out completo de) um processo inteiro, liberando seus frames para os demais rodarem sem thrashing — melhor sacrificar um do que travar todos. Essa ideia ecoa no OOM Killer do Linux (Parte VII).

Políticas de Alocação de Frames

Por fim: como distribuir os frames disponíveis entre os processos?

Alocação Global vs Local

Alocação local: cada processo tem um conjunto fixo de frames; ao precisar despejar, escolhe a vítima apenas entre suas próprias páginas. Oferece isolamento (o comportamento de um processo não afeta os outros), mas pode ser ineficiente — um processo pode ter frames sobrando enquanto outro passa fome.
Alocação global: a vítima é escolhida entre as páginas de todos os processos. Mais eficiente no uso agregado da memória, mas processos competem entre si — um processo "faminto" pode roubar frames de outros.

O Linux usa fundamentalmente uma abordagem global (o reclaim opera sobre LRU lists globais por zona/nó), mas os cgroups v2 (Parte VIII) reintroduzem fronteiras locais, permitindo limitar e isolar a memória por grupo de processos — o melhor dos dois mundos para containers.

Igual vs Proporcional

Ao alocar globalmente, como dividir? Igualmente entre processos é injusto (um processo pequeno não precisa do mesmo que um grande). A alocação proporcional dá frames na proporção do tamanho de cada processo, e variantes consideram prioridade — processos mais importantes recebem mais memória.

Esses conceitos teóricos são exatamente o que os controles de cgroup (memory.low, memory.high, memory.max) implementam na prática moderna — veremos na Parte VIII.

Continua na Parte VI, onde saímos da teoria e entramos numa das estruturas mais importantes (e menos compreendidas) do Linux: o page cache — o motivo pelo qual sua segunda leitura de um arquivo é instantânea — e o slab allocator, como o próprio kernel gerencia sua memória interna.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte IV

Alex Volnei Galante — Fri, 21 Aug 2026 00:49:49 +0000

[!NOTE]
Última parte do Artigo 2 (Fundamentos e Virtual Memory). Nas partes anteriores cobrimos hierarquia de memória, paginação, TLB, page faults, COW e swapping. Agora fechamos com zones e NUMA, a conexão com os runtimes de Python, .NET e Go, diagnóstico e boas práticas.

Sumário

Memory Zones
NUMA: quando a memória tem geografia
- Automatic NUMA Balancing
Conexão com Backend: Python (CPython)
Conexão com Backend: .NET (CLR)
Conexão com Backend: Go
Técnicas de Diagnóstico
Boas Práticas
Estudos de Caso
Referências Bibliográficas

Memory Zones

Até agora tratamos a RAM como um bloco uniforme de frames. Mas o kernel precisa lidar com restrições de hardware que tornam certas regiões da memória física especiais. Por isso ele divide a memória física em zones:

┌──────────────┬─────────────────────────────────────────────────────┐
│ ZONE_DMA     │ Memória para dispositivos antigos com endereçamento  │
│              │ limitado (ex.: primeiros 16 MB em x86)               │
├──────────────┼─────────────────────────────────────────────────────┤
│ ZONE_DMA32   │ Memória endereçável por dispositivos de 32 bits      │
│              │ (primeiros 4 GB)                                     │
├──────────────┼─────────────────────────────────────────────────────┤
│ ZONE_NORMAL  │ Memória "normal", diretamente mapeada pelo kernel.   │
│              │ Onde vive a maioria das alocações.                  │
├──────────────┼─────────────────────────────────────────────────────┤
│ ZONE_HIGHMEM │ (Relíquia do x86 32-bit; irrelevante em 64 bits)     │
└──────────────┴─────────────────────────────────────────────────────┘

Por que isso existe? Porque alguns dispositivos de hardware (especialmente antigos) só conseguem fazer DMA (acesso direto à memória) em faixas baixas de endereço. O kernel precisa garantir que buffers de DMA venham dessas zonas específicas. Em servidores modernos de 64 bits, a esmagadora maioria das alocações vem de ZONE_NORMAL, e você raramente pensa nas outras — mas elas aparecem quando você lê /proc/zoneinfo diagnosticando pressão de memória.

# Ver as zonas e suas watermarks (min/low/high — importantes no Artigo 3)
cat /proc/zoneinfo | grep -E 'Node|zone|free|min|low|high' | head -20

Cada zona tem suas próprias watermarks (min, low, high) que governam quando o kernel começa a recuperar memória — um mecanismo central que detalharemos no Artigo 3 (memory reclaim).

NUMA: quando a memória tem geografia

Em servidores com múltiplos sockets de CPU, a memória deixa de ser uniforme numa dimensão nova: a distância. Isso é o NUMA (Non-Uniform Memory Access).

Num sistema NUMA, cada socket de CPU (um nó NUMA) tem sua própria memória local, fisicamente próxima. Acessar a memória local é rápido; acessar a memória de outro nó (remota) passa pela interconexão entre sockets e é mais lento.

        Nó 0                             Nó 1
┌───────────────────┐                ┌───────────────────┐
│   CPUs 0-15       │                │   CPUs 16-31      │
│        │          │                │        │          │
│   ┌────┴────┐     │◀──────────────▶│   ┌────┴────┐     │
│   │ RAM     │     │  interconexão  │   │  RAM    │     │
│   │ local   │     │  (mais lenta)  │   │  local  │     │
│   └─────────┘     │                │   └─────────┘     │
└───────────────────┘                └───────────────────┘

 Acesso local:  ~100 ns          Acesso remoto: ~150-200 ns

A diferença de latência entre acesso local e remoto pode ser de 1.5x a 2x. Para aplicações sensíveis a latência, isso importa muito.

O kernel expõe a topologia e tenta, por padrão, alocar memória no mesmo nó onde a thread está rodando (política first-touch: a página vai para o nó que a tocou primeiro, não o que a alocou).

# Ver a topologia NUMA da máquina
numactl --hardware
# available: 2 nodes (0-1)
# node 0 cpus: 0 1 2 ... 15
# node 0 size: 64000 MB
# node 1 cpus: 16 17 ... 31
# node distances:
# node   0   1
#   0:  10  21     ← distância relativa (10 = local, 21 = ~2x mais lento)
#   1:  21  10

# Estatísticas NUMA por nó (hits locais vs faltas remotas)
numastat

A distance matrix (node distances) quantifica o custo relativo: 10 é o baseline local, e valores maiores indicam nós mais "distantes".

Automatic NUMA Balancing

Desde o Kernel 3.8, o Linux tem balanceamento automático de NUMA: ele monitora quais nós acessam quais páginas e migra páginas e threads para melhorar a localidade, dinamicamente. Isso usa uma técnica engenhosa: periodicamente desmapeia páginas (marcando PTEs como não-presentes) para forçar page faults "de amostragem" (NUMA hinting faults) que revelam o padrão de acesso.

# Verificar se está ativo (1 = ativo)
cat /proc/sys/kernel/numa_balancing

Para muitas aplicações isso é ótimo e transparente. Mas para workloads de altíssima performance e latência previsível (bancos de dados, trading, caches grandes), o balanceamento automático pode introduzir jitter — nesses casos, faz-se pinning explícito (fixar processo e memória a um nó via numactl), que veremos nas boas práticas.

Conexão com Backend: Python (CPython)

Agora conectamos tudo com o que roda de fato em produção. Começando pelo CPython.

O modelo de memória do CPython

O CPython tem seu próprio alocador em camadas sobre o malloc do sistema:

Objetos Python
      │
      ▼
┌──────────────┐  pymalloc: alocador especializado para objetos pequenos (< 512 bytes)
│  pymalloc    │  organiza memória em "arenas" (256 KB), "pools" (4 KB = 1 página!)
└──────┬───────┘  e "blocks". Reduz overhead de malloc para os milhões de objetinhos.
       │ (objetos grandes)
       ▼
┌──────────────┐
│  malloc/mmap │  → brk/mmap → kernel → page faults → frames físicos
└──────────────┘

Repare que um pool do pymalloc tem exatamente 4 KB — o tamanho de uma página. Não é coincidência: alinhar com a página evita desperdício e melhora a localidade.

Reference counting e page faults

Como vimos na Parte III, o refcount do CPython é uma escrita a cada toque num objeto. Isso tem duas consequências de memória:

Quebra de COW em workers pre-forked (discutido na Parte III) — o grande vilão do inchaço de memória em Gunicorn/uWSGI.
Dirty pages constantes: mesmo objetos "só de leitura" ficam sujos (dirty bit ligado), o que afeta reclaim e swap.

Fragmentação em aplicações long-running

Um problema clássico do CPython: memória liberada nem sempre volta ao SO. O pymalloc segura arenas, e a fragmentação da heap pode fazer o RSS de um worker só crescer, nunca diminuir, mesmo após picos de carga terminarem. É por isso que muitas equipes configuram Gunicorn com max_requests (recicla o worker após N requisições, devolvendo memória ao SO).

Diagnóstico prático

import tracemalloc

tracemalloc.start()
# ... executa a carga de trabalho ...
snapshot = tracemalloc.take_snapshot()
top = snapshot.statistics('lineno')
for stat in top[:10]:
    print(stat)   # mostra as linhas que mais alocam memória

# Correlacionar com o kernel: page faults do processo Python
perf stat -e minor-faults,major-faults -p <PID_python>

Mitigando o inchaço por COW

import gc

# ANTES do fork (no master), congela os objetos já criados na geração
# permanente, evitando que o GC toque seus headers e quebre o COW.
gc.freeze()
# ... então o Gunicorn/uWSGI faz fork dos workers ...

Estratégia complementar: manter dados grandes e imutáveis fora do heap gerenciado do Python — em arrays NumPy (buffer contíguo, sem refcount por elemento), em memória mapeada (mmap), ou num serviço externo (Redis). Assim os workers realmente compartilham, sem cópia.

Conexão com Backend: .NET (CLR)

O CLR (CoreCLR) no Linux tem um modelo de memória sofisticado, dominado pelo Garbage Collector.

Managed heap vs unmanaged memory

┌─────────────────────────────────────────────┐
│                Managed Heap                 │
│  ┌──────────────┐  ┌──────────────────────┐ │
│  │ SOH          │  │ LOH (Large Object    │ │
│  │ (Gen0/1/2)   │  │  Heap, ≥ 85 KB)      │ │
│  └──────────────┘  └──────────────────────┘ │
└─────────────────────────────────────────────┘
        │ o GC gerencia; sob o capô é tudo
        ▼ mmap/VirtualAlloc → páginas do kernel

O Small Object Heap (SOH) é geracional (Gen0, Gen1, Gen2), apostando que a maioria dos objetos morre jovem.
O Large Object Heap (LOH) guarda objetos ≥ 85 KB. Ele não é compactado por padrão (compactar objetos grandes é caro), então sofre de fragmentação externa — exatamente o conceito da Parte I reaparecendo. Buracos no LOH podem inflar o RSS.

GC e page faults

Um ciclo de GC "toca" muita memória (varrendo objetos, movendo-os na compactação do SOH). Isso pode disparar rajadas de page faults — inclusive major faults se parte da heap tiver ido para o swap. Um GC que precisa "puxar" a heap de volta do swap é uma fonte clássica de pausas longas em produção.

Workstation GC vs Server GC no Linux

Workstation GC: uma thread de GC, menor footprint. Bom para apps pequenas/desktop.
Server GC: uma heap e uma thread de GC por core, muito mais throughput — mas consome mais memória. Em containers, o Server GC pode alocar heaps por CPU do host, não do container, causando surpresas de consumo.

// runtimeconfig.json — atenção crítica em containers
{
  "configProperties": {
    "System.GC.Server": true,
    // Faz o CLR respeitar os limites de cgroup do container:
    "System.GC.HeapHardLimitPercent": 75
  }
}

[!IMPORTANT]
Em Kubernetes/containers, garanta que o CLR "enxerga" o limite de memória do cgroup. Versões modernas do .NET detectam cgroups automaticamente, mas vale verificar — senão o Server GC dimensiona a heap pela RAM do host e você toma OOM Kill (Artigo 3).

Diagnóstico

# Contadores de GC e memória ao vivo
dotnet-counters monitor -p <PID> --counters System.Runtime

# Coletar um dump para analisar a heap
dotnet-dump collect -p <PID>
dotnet-dump analyze core_dump
# > dumpheap -stat        (objetos por tipo/tamanho)
# > gcheapstat            (fragmentação por geração/LOH)

Conexão com Backend: Go

O runtime do Go tem um alocador inspirado no TCMalloc e um GC concorrente, com decisões que impactam diretamente o padrão de páginas.

Stack vs heap e escape analysis

O compilador Go decide, em tempo de compilação, se um valor vive na stack (barato, liberado ao retornar da função) ou "escapa" para a heap (gerenciado pelo GC). Isso é a escape analysis:

// NÃO escapa: 'x' vive na stack, zero pressão sobre o GC/heap.
func soma(a, b int) int {
    x := a + b
    return x
}

// ESCAPA: o ponteiro sobrevive à função → vai para a heap → pressão de GC.
func criaUsuario(nome string) *Usuario {
    u := Usuario{Nome: nome}
    return &u   // &u escapa
}

# Ver as decisões de escape analysis do compilador
go build -gcflags='-m' ./...
# ./main.go:12:9: &u escapes to heap

Menos alocações na heap = menos trabalho do GC = menos páginas sujas = menos pressão de memória no kernel. Otimizar escape analysis é otimizar a interação com o subsistema de memória do kernel.

O alocador e o kernel

O Go pede memória ao kernel em grandes blocos via mmap e os subdivide internamente em size classes (semelhante ao pymalloc e ao slab do kernel). O runtime tem seu próprio conceito de páginas (8 KB, dois frames de 4 KB) organizadas em spans.

Diagnóstico com pprof e GODEBUG

import _ "net/http/pprof"   // expõe profiles em /debug/pprof/

# Profile de heap: quem está alocando
go tool pprof http://localhost:6060/debug/pprof/heap

# Rastreio de cada ciclo de GC (pausa, heap, etc.)
GODEBUG=gctrace=1 ./minha-app
# gc 1 @0.012s 2%: 0.018+1.2+0.003 ms clock, ... 4->5->2 MB, 5 MB goal

# Correlacionar com page faults do kernel
perf stat -e minor-faults,major-faults ./minha-app

O GOGC (padrão 100) controla o trade-off: valores maiores = GC menos frequente = mais RAM usada, menos CPU em GC. O GOMEMLIMIT (Go 1.19+) define um teto suave de memória — essencial em containers para evitar OOM Kill, funcionando como um "freio" antes de o cgroup estourar.

Técnicas de Diagnóstico

Um resumo do arsenal para investigar memória em produção, conectando com tudo que vimos:

# 1. Visão geral do processo: virtual vs residente
pmap -x <PID>                    # mapa detalhado com RSS por região
ps -o pid,vsz,rss,cmd -p <PID>   # VSZ (virtual) vs RSS (físico)

# 2. Detalhamento por VMA: dirty pages, PSS (proporcional), swap
cat /proc/<PID>/smaps            # rico, porém verboso
grep -E 'Rss|Pss|Swap' /proc/<PID>/smaps_rollup   # resumo agregado

# 3. Page faults (minor = RAM, major = disco!)
perf stat -e minor-faults,major-faults -p <PID>

# 4. Pressão de memória do sistema
vmstat 1                         # colunas si/so (swap in/out) → alerta!
free -h

# 5. Transparent Huge Pages em uso
grep -i AnonHugePages /proc/<PID>/smaps_rollup

# 6. NUMA: acessos locais vs remotos
numastat -p <PID>

PSS (Proportional Set Size) merece destaque: quando várias instâncias compartilham páginas (código, COW), o RSS conta a página inteira para cada processo, superestimando o total. O PSS divide páginas compartilhadas proporcionalmente, dando uma medida mais honesta de "quanto este processo realmente custa" de memória.

Boas Práticas

Dimensione heaps explicitamente em containers. Configure GOMEMLIMIT (Go), HeapHardLimitPercent (.NET) e limites de worker (Python/Gunicorn max_requests). Nunca confie que o runtime vai adivinhar o limite do cgroup — verifique.
Use huge pages para databases e caches grandes, mas com critério. Habilite HugeTLB explícito para o banco; desabilite THP (madvise ou never) se sua stack (Redis, Mongo, PostgreSQL) recomenda, para evitar jitter de latência.
NUMA pinning para aplicações latency-sensitive. Fixe processo e memória ao mesmo nó:

   numactl --cpunodebind=0 --membind=0 ./minha-app-critica

Preserve o COW em workers Python pre-forked: gc.freeze() antes do fork, dados grandes fora do heap gerenciado.
Configure swap conscientemente em containers. Em SSD/NVMe, um swap moderado pode ser um amortecedor útil (kernels 5.14+ o tornaram eficiente), mas ajuste vm.swappiness conforme o workload (aprofundamos no Artigo 3).

Estudos de Caso

1. Python — Otimizando um cliente Redis com huge pages

Uma aplicação de cache intensivo com grandes estruturas em memória sofria com TLB misses (working set de vários GB, muitas páginas de 4 KB). Habilitar huge pages para a região de dados reduziu a pressão sobre a TLB, cortando a latência de cauda (p99) de acessos ao cache. Diagnóstico feito com perf stat -e dTLB-load-misses.

2. .NET — Tuning de GC para uma API de alta vazão

Uma API ASP.NET Core em Kubernetes tomava OOM Kill esporádico. Investigação com dotnet-counters mostrou o Server GC dimensionando a heap pela RAM do host (não do container). Correção: HeapHardLimitPercent no runtimeconfig + verificação da detecção de cgroup. RSS estabilizou abaixo do limite e o OOM sumiu.

3. Go — Reduzindo allocation pressure em um stream processor

Um processador de streams tinha ciclos de GC frequentes (visíveis em GODEBUG=gctrace=1) causando picos de CPU. go build -gcflags='-m' revelou allocations desnecessárias na heap (buffers escapando em hot path). Reuso via sync.Pool e ajuste de GOGC reduziram a frequência de GC e a quantidade de páginas sujas por segundo.

Continua na Parte V
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte III

Alex Volnei Galante — Fri, 21 Aug 2026 00:46:12 +0000

[!NOTE]
Continuação da série. Na Parte II cobrimos paginação, tabelas de páginas multinível (PGD/PUD/PMD/PTE), TLB e segmentação. Agora entramos na parte dinâmica: o que acontece em tempo de execução quando seu processo toca a memória.

Sumário

Page Faults: o coração da memória virtual
- Minor vs Major faults
- A sequência de tratamento
Demand Paging
Copy-on-Write: por que fork() é barato
Zero-fill on Demand
O Memory Layout de um processo real
- Lendo /proc/pid/maps
- mmap: o canivete suíço da memória
- ASLR
Paging e Swapping modernos
- Páginas anônimas vs file-backed
Referências Bibliográficas

Page Faults: o coração da memória virtual

Na Parte II vimos o bit Present na PTE. Quando a MMU tenta traduzir um endereço virtual e encontra uma PTE com Present = 0 (ou uma violação de permissão), ela dispara uma exceção de hardware: o page fault. O controle passa imediatamente ao kernel, que decide o que fazer.

É crucial entender: page faults são normais e esperados. Eles não são erros — são o mecanismo pelo qual a memória virtual funciona. Seu processo dispara milhares deles por segundo, e a maioria é resolvida em nanossegundos.

Minor vs Major faults

A distinção mais importante para diagnóstico em produção:

Minor fault (soft fault): a página já está na RAM, mas não havia mapeamento na tabela de páginas daquele processo. O kernel só precisa criar a PTE. É rápido — não envolve disco. Exemplos: primeira escrita numa página recém-alocada, compartilhamento de uma biblioteca já carregada por outro processo, acesso a uma página que estava no page cache.
Major fault (hard fault): a página não está na RAM e precisa ser trazida do disco (do swap, ou de um arquivo mapeado). Envolve I/O de disco, então é ordens de magnitude mais lento — pode custar milissegundos. Uma rajada de major faults é um sintoma clássico de pressão de memória ou thrashing.

# Ver minor e major faults de um processo (colunas min_flt e maj_flt)
ps -o min_flt,maj_flt,cmd -p <PID>

# Monitorar page faults ao vivo
perf stat -e minor-faults,major-faults -p <PID>

# Faults do sistema inteiro (campos pgfault, pgmajfault)
grep -E 'pgfault|pgmajfault' /proc/vmstat

Regra de ouro para produção: um número alto de minor faults é geralmente inofensivo (é só a aplicação alocando memória). Um número alto e crescente de major faults é um alarme — significa que seu processo está batendo no disco para acessar memória, o que destrói a latência.

Agora vamos falar a verdade pura, 99% dos desenvolvedores nunca fizeram esse tipo de troubleshooting, mas é fundamental para backend: entender page faults, demand paging, COW e zero-fill on demand é o que separa um engenheiro que entende de memória de um que só sabe alocar objetos e esperar que o GC resolva.

A sequência de tratamento

Quando um page fault ocorre, o handler do kernel (do_page_fault no x86) segue, simplificadamente:

1. A MMU dispara o fault e informa o endereço que causou o problema (registrador CR2 no x86).
2. O kernel consulta as VMAs (Virtual Memory Areas) do processo:
     - O endereço pertence a alguma região válida do processo?
        └── NÃO → SIGSEGV (segmentation fault). Processo geralmente morre.
        └── SIM → continua.
3. O acesso é permitido? (ex: escrita numa página read-only)
        └── Violação real → SIGSEGV
        └── É Copy-on-Write → copia a página, marca como writable (ver adiante)
4. A página está na RAM?
        └── SIM (minor) → cria/atualiza a PTE, retoma a execução
        └── NÃO (major) → aloca frame, busca do disco/swap, cria PTE, retoma

Repare que o mesmo mecanismo — o page fault — serve a vários propósitos: detectar acessos inválidos (SIGSEGV), implementar demand paging, viabilizar Copy-on-Write e trazer páginas do swap. É um dos designs mais elegantes de todo o kernel.

Demand Paging

Munidos do conceito de page fault, entendemos o demand paging: o kernel não carrega um programa inteiro na memória quando ele inicia. Em vez disso, carrega páginas sob demanda, conforme são realmente acessadas.

Quando você executa um binário de 200 MB:

O kernel mapeia o arquivo no espaço virtual do processo (via mmap), mas quase nada é carregado na RAM ainda. As PTEs estão com Present = 0.
A execução começa. A primeira instrução dispara um page fault → o kernel carrega aquela página do binário.
Conforme a execução avança e toca novas páginas, cada uma é trazida sob demanda.

O resultado: um processo com 200 MB de binário pode iniciar tocando só alguns MB — exatamente o seu working set inicial. Isso torna a inicialização rápida e economiza RAM enormemente, especialmente quando várias instâncias do mesmo binário rodam (elas compartilham as páginas de código, read-only, na RAM).

Conexão backend: é por isso que o RSS (Resident Set Size) de um processo recém-iniciado é muito menor que o tamanho virtual (VSZ). O processo "reservou" um espaço virtual grande, mas só uma fração está fisicamente residente.

# VSZ (virtual) vs RSS (residente físico)
ps -o vsz,rss,cmd -p <PID>
#   VSZ      RSS   CMD
# 2415616   85320  python app.py   → reservou ~2.4 GB virtual, usa ~85 MB físico

Copy-on-Write: por que fork() é barato

Este é, talvez, o conceito de memória virtual com maior impacto direto em backend, especialmente no mundo Python.

Quando um processo faz fork(), o kernel precisa criar um filho com uma cópia do espaço de endereçamento do pai. Copiar gigabytes de memória a cada fork() seria proibitivo. A solução é o Copy-on-Write (COW):

Logo após fork():

  Pai  ──┐
         ├──▶ [Página compartilhada, marcada READ-ONLY na PTE de ambos]
  Filho ─┘

Quando um deles TENTA ESCREVER:
  1. A escrita numa página read-only dispara um page fault
  2. O kernel percebe que é COW (não uma violação real)
  3. Copia a página para um novo frame
  4. Marca a cópia como writable para quem escreveu
  5. Retoma a execução

  Pai  ──▶ [Página original]
  Filho ──▶ [Cópia privada]     ← só agora houve cópia real

Ou seja: pai e filho compartilham fisicamente todas as páginas até que uma delas seja modificada. Só as páginas efetivamente escritas são copiadas. Páginas apenas lidas (como o código) nunca são copiadas.

O impacto em workers pre-forked (Python/Gunicorn/uWSGI)

Servidores Python usam o modelo pre-fork: um processo master carrega a aplicação e faz fork() de vários workers. Em teoria, graças ao COW, os workers compartilham toda a memória do master (código, dados carregados no import), consumindo pouca RAM adicional cada.

Na prática, há uma armadilha traiçoeira: o reference counting do CPython. Toda vez que o Python toca um objeto — mesmo só para ler — ele incrementa e decrementa o campo ob_refcnt na struct do objeto. Isso é uma escrita na página onde o objeto vive, o que quebra o COW: a página é copiada, mesmo que você só quisesse ler o objeto.

# Antipadrão para COW em Python pre-forked:
# um objeto grande no master, "só de leitura" nos workers.

CONFIG_GIGANTE = carregar_dados_enormes()   # no master, antes do fork

def handler(request):
    # Mesmo APENAS LENDO, o refcount de CONFIG_GIGANTE (e dos objetos
    # internos tocados) é incrementado/decrementado → escrita na página
    # → COW dispara → a página "compartilhada" é copiada para o worker.
    return CONFIG_GIGANTE[request.chave]

O resultado é o famoso fenômeno de workers Python que incham com o tempo: memória que deveria ser compartilhada acaba sendo copiada worker a worker. Estratégias de mitigação (usar estruturas fora do heap gerenciado, como arrays NumPy ou mmap, mover dados para um processo/serviço externo como Redis) serão discutidas na Parte IV, junto com a conexão CPython.

[!TIP]
O gc.freeze() (Python 3.7+) move os objetos existentes para uma geração "permanente" antes do fork, evitando que o garbage collector toque os headers deles e quebre o COW. É uma otimização valiosa para workers pre-forked.

Zero-fill on Demand

Quando seu programa pede memória nova (via malloc/brk/mmap anônimo), o kernel não aloca frames físicos imediatamente. Ele apenas registra que aquela região virtual existe. Mais que isso: por segurança, memória nova precisa ser zerada (senão você leria lixo — possivelmente dados sensíveis de outro processo).

O kernel otimiza isso com uma página especial: a zero page. Todas as páginas anônimas recém-alocadas são inicialmente mapeadas (read-only) para uma única página física preenchida com zeros:

malloc(1 GB):
  - Nenhum frame físico é alocado ainda.
  - Todas as páginas virtuais apontam (read-only) para a MESMA zero page.
  - RSS quase não muda!

Primeira ESCRITA em uma página:
  - Page fault (COW sobre a zero page)
  - Aí sim o kernel aloca um frame real, zerado, e o torna privado/writable.

Conexão backend: é por isso que malloc de 1 GB retorna instantaneamente e o RSS mal se move. A memória só é "materializada" quando escrita pela primeira vez. Isso explica por que ferramentas de monitoramento mostram um processo "alocando" muita memória virtual mas com RSS baixo — e por que o consumo real de RAM cresce conforme a aplicação usa (escreve) a memória, não quando a reserva. Isso é o overcommit de memória, e é também por que o OOM Killer (Artigo 3) pode aparecer "do nada": o kernel prometeu mais memória do que tem, apostando que nem todos vão escrever tudo.

O Memory Layout de um processo real

Vamos juntar tudo e olhar como um processo Linux organiza seu espaço virtual. Aqueles "segmentos" lógicos da Parte II aparecem aqui, implementados sobre paginação:

Text: o código executável. Read-only e compartilhável entre processos.
Data / BSS: variáveis globais. Data tem valores iniciais no binário; BSS é zero-fill on demand.
Heap: cresce "para cima" via brk/sbrk. É onde vivem os objetos dinâmicos (o heap do malloc, do CPython, do CLR, do Go).
mmap region: onde ficam bibliotecas compartilhadas, arquivos mapeados e grandes alocações (allocadores modernos usam mmap para blocos grandes em vez de brk).
Stack: cresce "para baixo". Cada thread tem sua própria stack.

Lendo /proc/pid/maps

O Linux expõe esse layout num arquivo legível. É uma das ferramentas de diagnóstico de memória mais úteis que existem:

cat /proc/self/maps

55a3c0000000-55a3c0021000 r--p 00000000 08:01 1311  /usr/bin/python3.11   ← text (read-only)
55a3c0021000-55a3c0200000 r-xp 00021000 08:01 1311  /usr/bin/python3.11   ← código executável
55a3c0400000-55a3c0500000 rw-p 00000000 00:00 0                           ← heap (anônimo, rw)
7f2a4c000000-7f2a4c021000 r-xp 00000000 08:01 2201  /lib/libc.so.6        ← libc mapeada
7ffe1a3c0000-7ffe1a3e1000 rw-p 00000000 00:00 0     [stack]               ← stack

Cada linha é uma VMA (Virtual Memory Area) — uma região contígua com as mesmas permissões. As colunas de permissão (r, w, x, p=private/s=shared) refletem exatamente os bits de proteção das PTEs que vimos na Parte II. Para detalhamento de uso físico por região, existe /proc/pid/smaps (mostra RSS, PSS, dirty pages por VMA) — voltaremos a ele nas técnicas de diagnóstico da Parte IV.

mmap: o canivete suíço da memória

A syscall mmap mapeia algo diretamente no espaço de endereçamento do processo. Ela é fundamental e aparece em todo lugar:

mmap anônimo: aloca memória "pura" (é o que malloc usa para blocos grandes).
mmap de arquivo: mapeia um arquivo na memória, permitindo lê-lo/escrevê-lo como se fosse um array — o kernel cuida do I/O via page faults e page cache (tema central do Artigo 3).
mmap compartilhado: várias instâncias mapeiam a mesma região → memória compartilhada entre processos.

import mmap

# Mapeia um arquivo grande sem carregá-lo inteiro na RAM.
# O acesso dispara page faults que trazem só as páginas tocadas.
with open("dados_gigantes.bin", "rb") as f:
    mm = mmap.mmap(f.fileno(), 0, prot=mmap.PROT_READ)
    primeiro_registro = mm[0:1024]   # só esta página é trazida do disco
    mm.close()

Cada linguagem tem seu equivalente: MemoryMappedFile no .NET, syscall.Mmap/mmap no Go. Exploraremos esses padrões no Artigo 3, sobre page cache.

ASLR

O ASLR (Address Space Layout Randomization) é uma defesa de segurança: a cada execução, o kernel randomiza as posições da stack, do heap, das bibliotecas e (com PIE) do próprio código. Isso dificulta ataques que dependem de saber endereços fixos (como ROP/return-to-libc).

# Status global do ASLR (2 = totalmente ativado, o padrão)
cat /proc/sys/kernel/randomize_va_space

# Rode 'cat /proc/self/maps | grep stack' duas vezes:
# o endereço da [stack] muda a cada execução → ASLR em ação.

Kernels 6.x trouxeram melhorias na entropia e granularidade do ASLR. Para backend, o impacto é quase sempre transparente — mas vale saber que ele existe quando você vê endereços diferentes a cada boot da aplicação, e que desabilitá-lo (algo que às vezes se faz para debugging) reduz a segurança.

Paging e Swapping modernos

Fechamos com o swapping — mas agora, com paginação, ele é muito mais refinado que o swapping clássico de processos inteiros da Parte I. O kernel move páginas individuais entre a RAM e o disco, não processos inteiros.

Quando a memória fica escassa, o kernel escolhe páginas "frias" (pouco usadas — lembra dos bits Accessed/Dirty?) e as move para a área de swap no disco, liberando frames. Se a página for acessada depois, um major fault a traz de volta. Os algoritmos que decidem quais páginas remover são um tópico rico — e são exatamente o assunto de abertura do Artigo 3 (algoritmos de substituição, working set, thrashing).

Páginas anônimas vs file-backed

Uma distinção que o kernel faz o tempo todo, e que você precisa conhecer:

Páginas file-backed: têm uma "casa" no disco — um arquivo. Código, bibliotecas, arquivos mapeados. Quando o kernel precisa liberá-las, se estiverem limpas (não modificadas), basta descartá-las — o conteúdo pode ser relido do arquivo original quando necessário. Não precisam de swap.
Páginas anônimas: não têm arquivo de origem — heap, stack, memória de malloc. Elas não têm para onde voltar a não ser o swap. Se não há swap configurado e a memória acaba, o kernel não tem como liberá-las → é aí que o OOM Killer entra em cena.

# Ver uso de swap do sistema
free -h
#               total   usado   livre   compart.  buff/cache
# Mem:          15Gi    8Gi     1Gi     200Mi     6Gi
# Swap:         4Gi     512Mi   3Gi

# Swap por processo (VmSwap)
grep VmSwap /proc/<PID>/status

O parâmetro vm.swappiness controla o quão agressivamente o kernel prefere fazer swap de páginas anônimas versus descartar páginas de cache — mas esse é um assunto de tuning que aprofundaremos no Artigo 3, junto com memory reclaim e pressão de memória.

Kernels 5.14+ trouxeram melhorias importantes no swap para dispositivos rápidos (SSD/NVMe), tornando o swap muito menos "assustador" do que era na era dos HDDs — em SSD, o swap pode ser uma ferramenta legítima de gestão de memória, não apenas um último recurso.

Continua na Parte IV, onde fechamos o Artigo 2 com Memory Zones e NUMA, a conexão profunda com os runtimes de Python, .NET e Go, técnicas de diagnóstico (/proc/pid/smaps, pmap, perf, numastat), boas práticas e estudos de caso reais.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte II

Alex Volnei Galante — Fri, 21 Aug 2026 00:41:37 +0000

[!NOTE]
Este artigo é a continuação da Parte I, onde estabelecemos a hierarquia de memória, a evolução do gerenciamento sem abstração, o conceito de espaço de endereçamento e a introdução à MMU. Se você ainda não leu, recomendo começar por lá.

Sumário

Paginação: a ideia central
- Páginas e Frames
- Anatomia de um endereço virtual
A Tabela de Páginas
- O formato de uma entrada (PTE)
- O problema do tamanho
Tabelas de Páginas Multinível
- A hierarquia do Linux: PGD, PUD, PMD, PTE
- 4 e 5 níveis: endereçamento de 48 e 57 bits
- Alternativas: tabelas invertidas e hashed
A TLB: Translation Lookaside Buffer
- Cálculo do tempo efetivo de acesso
- TLB e context switch: flush vs ASID
Huge Pages e THP
Segmentação
Referências Bibliográficas

Paginação: a ideia central

Na Parte I vimos que o swapping clássico tinha um defeito fatal: sua granularidade grosseira, movendo processos inteiros entre RAM e disco. A paginação resolve isso quebrando a memória em pedaços pequenos e de tamanho fixo, permitindo mover, mapear e proteger memória com granularidade fina.

Páginas e Frames

A paginação divide os dois mundos em unidades de mesmo tamanho:

O espaço virtual é dividido em páginas (pages).
A memória física é dividida em frames (page frames).
Página e frame têm o mesmo tamanho — no x86-64, o padrão é 4 KB (4096 bytes).

A tarefa da paginação é manter um mapeamento: qual página virtual está em qual frame físico. Como página e frame têm o mesmo tamanho, esse mapeamento é uma simples tabela de correspondência.

Anatomia de um endereço virtual

A grande sacada da paginação é como um endereço virtual é interpretado. Ele é dividido em duas partes: o número da página e o offset dentro da página.

Com páginas de 4 KB ($2^{12}$ bytes), os 12 bits mais baixos do endereço são o offset (0 a 4095), e os bits restantes identificam a página:

Endereço virtual de 48 bits (x86-64 típico):

 47                                  12 11                    0
┌──────────────────────────────────────┬───────────────────────┐
│         Número da Página (36 bits)   │    Offset (12 bits)   │
└──────────────────────────────────────┴───────────────────────┘

Tradução:
  - Número da página → consulta tabela → Número do Frame (PFN)
  - Offset → copiado DIRETAMENTE, sem tradução

O detalhe elegante: o offset não é traduzido. Se um endereço virtual está a 100 bytes do início de sua página, o endereço físico correspondente está a 100 bytes do início do frame. Só o número da página passa pela tradução. Isso simplifica enormemente o hardware.

A Tabela de Páginas

A estrutura que guarda o mapeamento página → frame é a tabela de páginas (page table). Cada processo tem a sua própria — é isso que garante que o endereço virtual 0x1000 do processo A e do processo B apontem para frames físicos diferentes.

O formato de uma entrada (PTE)

Cada entrada da tabela de páginas — a PTE (Page Table Entry) — contém muito mais que apenas o número do frame. Ela carrega bits de controle que o hardware e o kernel usam constantemente:

Estrutura simplificada de uma PTE no x86-64:

 63    62         52 51            12 11        9 8 7 6 5 4 3 2 1 0
┌──┬─────────────────┬───────────────┬──────────┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│NX│  reservado      │  PFN (frame)  │  livre   │G│P│D│A│C│W│U│W│P│P│
└──┴─────────────────┴───────────────┴──────────┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘

Bits de controle essenciais:
  P  (Present)     → a página está na RAM? (0 = page fault ao acessar)
  W  (Writable)    → pode escrever? (proteção de escrita)
  U  (User)        → acessível em user mode? (proteção kernel/user)
  A  (Accessed)    → foi referenciada? (usado por algoritmos de reposição)
  D  (Dirty)       → foi modificada? (precisa gravar no disco antes de descartar)
  NX (No eXecute)  → impede execução de código (proteção contra exploits)
  PFN              → o Page Frame Number: qual frame físico

Esses bits não são detalhes acadêmicos — eles são a base de mecanismos que impactam produção diretamente:

O bit Present é o que dispara page faults e viabiliza demand paging e swapping (Parte III).
O bit Writable é o que torna possível o Copy-on-Write no fork() (Parte III).
Os bits Accessed e Dirty alimentam os algoritmos de reposição de página (Parte V do Artigo 3).
O bit NX é uma defesa de segurança fundamental contra ataques de execução de código na stack/heap.

O problema do tamanho

Aqui surge um problema sério. Imagine uma tabela de páginas "plana" (single-level) para um espaço de 48 bits com páginas de 4 KB:

Número de páginas: $2^{48} / 2^{12} = 2^{36}$ páginas.
Se cada PTE ocupa 8 bytes: $2^{36} \times 8 = 2^{39}$ bytes = 512 GB de tabela de páginas.

Por processo! Isso é obviamente inviável. E o pior: a maioria dos processos usa apenas uma fração ínfima do seu espaço virtual, então a tabela seria quase toda preenchida com entradas vazias. Precisamos de algo mais inteligente.

Tabelas de Páginas Multinível

A solução é não alocar a tabela inteira de uma vez, mas organizá-la em uma hierarquia de níveis, alocando apenas os pedaços realmente usados. É o mesmo princípio de um índice de livro com capítulos e seções: você não lista todas as páginas, mas navega por níveis.

A hierarquia do Linux: PGD, PUD, PMD, PTE

O Linux implementa uma tabela de páginas de 4 níveis (no x86-64 clássico). O endereço virtual é fatiado em vários campos, cada um indexando um nível:

Endereço virtual de 48 bits, fatiado em 4 níveis + offset:

 47      39 38      30 29      21 20      12 11         0
┌──────────┬──────────┬──────────┬──────────┬────────────┐
│  PGD idx │  PUD idx │  PMD idx │  PTE idx │   offset   │
│ (9 bits) │ (9 bits) │ (9 bits) │ (9 bits) │ (12 bits)  │
└──────────┴──────────┴──────────┴──────────┴────────────┘

Os nomes usados no código-fonte do kernel Linux:

PGD — Page Global Directory (nível mais alto; o registrador CR3 aponta para ele)
PUD — Page Upper Directory
PMD — Page Middle Directory
PTE — Page Table Entry (nível mais baixo, aponta para o frame físico)

O processo de tradução (o "page table walk") segue os níveis:

CR3 ──▶ [PGD] ──idx──▶ [PUD] ──idx──▶ [PMD] ──idx──▶ [PTE] ──▶ Frame físico
         │                                                          │
         └── cada nível tem 512 entradas (2^9)                      └── + offset = endereço físico

A economia é brutal: um processo que usa poucos MB de memória precisa de apenas alguns níveis alocados, não os 512 GB da tabela plana. Os ramos não utilizados simplesmente não existem.

O custo? Cada acesso à memória agora exige 4 acessos adicionais à RAM (um por nível) só para traduzir o endereço. Um único mov do seu programa pode virar 5 acessos à memória. É exatamente esse custo que a TLB, que veremos a seguir, existe para eliminar.

4 e 5 níveis: endereçamento de 48 e 57 bits

Por muito tempo, 48 bits de endereçamento virtual (256 TB) foram mais que suficientes. Mas servidores com muitos terabytes de RAM e workloads como bancos de dados in-memory começaram a esbarrar nesse teto.

A partir do Kernel 4.14 (e amplamente disponível nos kernels 5.x), o Linux passou a suportar tabelas de páginas de 5 níveis, adicionando um nível chamado P4D entre o PGD e o PUD:

5 níveis → endereçamento virtual de 57 bits → 128 PB de espaço virtual

 56    48 47    39 38    30 29    21 20    12 11      0
┌────────┬────────┬────────┬────────┬────────┬──────────┐
│ PGD    │ P4D    │ PUD    │ PMD    │ PTE    │  offset  │
└────────┴────────┴────────┴────────┴────────┴──────────┘

Para a maioria das aplicações backend isso é transparente — você não muda uma linha de código. Mas se você opera bancos de dados gigantes, caches in-memory de múltiplos terabytes ou máquinas com RAM massiva, é o kernel removendo um teto que antes existia.

Alternativas: tabelas invertidas e hashed

O modelo multinível é o dominante, mas vale conhecer as alternativas que Tanenbaum discute:

Tabela de páginas invertida: em vez de uma entrada por página virtual (que pode ser enorme), há uma entrada por frame físico. O tamanho passa a ser proporcional à RAM, não ao espaço virtual. A desvantagem é que a busca vira uma pesquisa (geralmente via hash), não uma indexação direta. Usada em arquiteturas como PowerPC e Itanium.
Hashed page tables: usam uma função hash sobre o número da página virtual para encontrar a entrada. Comuns em espaços de endereçamento esparsos de 64 bits.

O x86-64, arquitetura da esmagadora maioria dos servidores, usa o modelo multinível hierárquico que detalhamos acima.

"Gosto de pensar no Tanenbaum como cara com mesmo senso crítico que Albert Einstein, que não se contenta com o que é popular, mas sim com o que é elegante e eficiente. Ele discute alternativas, mas o x86-64 escolheu a hierarquia multinível por ser simples e eficiente na prática." Alex Volnei Galante (Eu mesmo kkkk)

A TLB: Translation Lookaside Buffer

Se cada acesso à memória exige um page table walk de 4 ou 5 acessos adicionais à RAM, a paginação seria proibitivamente lenta. A solução é um cache dedicado a traduções: a TLB (Translation Lookaside Buffer).

A TLB é um cache pequeno e ultrarrápido, dentro da MMU, que guarda as traduções página→frame usadas recentemente:

Acesso à memória com TLB:

  endereço virtual
        │
        ▼
   ┌─────────┐   TLB hit (~1 ciclo)
   │   TLB   │─────────────────────▶ endereço físico   ✔ rápido!
   └─────────┘
        │ TLB miss
        ▼
   ┌─────────────┐
   │ Page Table  │  walk de 4-5 níveis (~100+ ciclos)
   │   Walk      │─────────────────────▶ endereço físico + preenche TLB
   └─────────────┘

Graças à localidade (de novo ela!), a TLB tem uma taxa de acerto (hit ratio) altíssima na prática — tipicamente acima de 99%. A maioria dos acessos nunca chega a fazer o walk completo.

Cálculo do tempo efetivo de acesso

Vale fazer a conta para sentir o impacto. Suponha:

Acesso à RAM: 100 ns
TLB hit: adiciona ~0 ns (acontece em paralelo)
TLB miss: exige um page walk que custa, digamos, 4 acessos à RAM = 400 ns extras

A lição prática: TLB misses são caros. Workloads que "pulam" por muita memória de forma aleatória (bancos de dados percorrendo índices grandes, por exemplo) sofrem com TLB misses. É por isso que huge pages, que veremos adiante, podem dar ganhos expressivos.

TLB e context switch: flush vs ASID

Aqui está um ponto que conecta diretamente com o Artigo 1 (context switching). Cada processo tem sua própria tabela de páginas, então o endereço virtual 0x1000 significa coisas diferentes para processos diferentes. O que acontece com a TLB quando o kernel troca de processo?

Abordagem ingênua (flush): esvaziar a TLB inteira a cada context switch. Correto, mas caro — o novo processo começa com a TLB "fria" e sofre uma rajada de TLB misses até reaquecê-la. Esse é um dos custos indiretos do context switch que mencionamos no Artigo 1.
Abordagem moderna (ASID/PCID): cada entrada da TLB é etiquetada com um identificador de espaço de endereçamento — ASID (Address Space ID) na terminologia genérica, PCID (Process Context ID) no x86-64. Assim, entradas de processos diferentes coexistem na TLB sem conflito, e o flush deixa de ser necessário na maioria dos switches.

Isso reforça uma ideia da série: aplicações com muitos context switches (por exemplo, muitas threads competindo, ou muito chaveamento entre goroutines que bloqueiam em syscalls) pagam um custo em memória, não só em CPU. Menos switches = TLB mais quente = menos latência.

Huge Pages e THP

Se páginas de 4 KB geram pressão sobre a TLB (cada entrada cobre só 4 KB), a solução é usar páginas maiores. O x86-64 suporta:

Páginas de 2 MB (usando um nível a menos no walk — o PMD aponta direto para o frame)
Páginas de 1 GB (o PUD aponta direto para o frame)

Uma única entrada de TLB para uma página de 2 MB cobre o que exigiria 512 entradas de 4 KB. Para workloads com grande footprint de memória, isso reduz drasticamente os TLB misses.

Há duas formas de usá-las no Linux:

HugeTLB (explícito): você reserva páginas grandes antecipadamente e a aplicação as requisita explicitamente. É o modelo usado por bancos de dados como Oracle e PostgreSQL (via huge_pages).
Transparent Huge Pages (THP): o kernel tenta usar huge pages automaticamente, promovendo regiões de 4 KB para 2 MB quando possível, sem intervenção da aplicação.

# Verificar status do THP no sistema
cat /sys/kernel/mm/transparent_hugepage/enabled
# [always] madvise never

# Ver quanta memória está em huge pages
grep -i huge /proc/meminfo
# AnonHugePages:    524288 kB
# HugePages_Total:       0
# HugePages_Free:        0

⚠️ Cuidado em produção: THP nem sempre é benéfico. Muitos bancos de dados (Redis, MongoDB, PostgreSQL) recomendam desabilitar o THP, porque a promoção/compactação de páginas em background pode causar picos de latência imprevisíveis e fragmentação. A recomendação comum é usar madvise (só onde a aplicação pede via madvise(MADV_HUGEPAGE)) em vez de always. Voltaremos a huge pages nas boas práticas da Parte IV.

Segmentação

Antes de fechar, vale entender a segmentação — uma abordagem alternativa (e complementar) à paginação, que Tanenbaum trata em detalhe.

Enquanto a paginação divide a memória em pedaços de tamanho fixo e sem significado semântico (uma página é só 4 KB de bytes), a segmentação divide o espaço de endereçamento em unidades lógicas de tamanho variável que correspondem à estrutura do programa:

Visão segmentada de um processo:

┌──────────────────┐  Segmento 0: código (text)
├──────────────────┤  Segmento 1: dados globais (data)
├──────────────────┤  Segmento 2: heap
├──────────────────┤  Segmento 3: stack
└──────────────────┘

Cada segmento tem base, limite e permissões próprias.

A vantagem da segmentação é semântica: cada segmento pode ter proteções próprias (código = read-only + executável; stack = read-write + no-execute) e crescer independentemente. A desvantagem é que segmentos de tamanho variável trazem de volta o fantasma da fragmentação externa.

Segmentação vs Paginação

Aspecto	Paginação	Segmentação
Tamanho da unidade	Fixo (4 KB)	Variável
Fragmentação	Interna	Externa
Visão do programador	Transparente	Explícita (às vezes)
Proteção	Por página	Por segmento (semântica)

Segmentação paginada (x86)

A arquitetura x86 historicamente combinou as duas: segmentação paginada. Um endereço passava primeiro pela segmentação (segmento + offset → endereço linear) e depois pela paginação (endereço linear → físico).

Na prática, porém, o x86-64 praticamente aposentou a segmentação. No modo de 64 bits, a maioria dos registradores de segmento tem base fixada em 0 e limite "infinito" — ou seja, a segmentação é neutralizada, e o Linux usa essencialmente um modelo de memória plano baseado só em paginação. Os conceitos de "segmentos" que sobrevivem (text, data, heap, stack) são hoje uma organização lógica implementada sobre paginação, não segmentação de hardware. Veremos esse memory layout na próxima parte.

Continua na Parte III, onde entramos no coração dinâmico da memória virtual: page faults (minor e major), demand paging, o Copy-on-Write que torna o fork() barato, o memory layout de um processo real (com mmap, ASLR) e o swapping moderno.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Gerenciamento de Memória Parte I

Alex Volnei Galante — Fri, 21 Aug 2026 00:33:34 +0000

Se você acompanhou a série sobre Processos & Threads, já entende como o kernel do Linux cria a ilusão de que cada processo tem uma CPU só para si. Agora vamos atacar a segunda grande ilusão que o kernel constrói: a de que cada processo tem uma memória infinita e exclusiva só para ele.

Assim como fizemos com processos, o objetivo aqui não é decorar estruturas do kernel, mas entender como o código que escrevemos em produção — seja em Python, .NET ou Go — interage com o subsistema de gerenciamento de memória, e como esse entendimento nos torna melhores em diagnosticar problemas de performance, consumo de RAM e latência.

Motivação

Toda aplicação backend, sem exceção, é limitada por dois recursos fundamentais: CPU e memória. Já cobrimos CPU na série anterior. Agora vamos falar de memória — o recurso que, quando mal compreendido, causa os problemas mais silenciosos e traiçoeiros em produção: memory leaks que derrubam containers no meio da madrugada, o temido OOM Killer matando seu worker sem explicação aparente, latência de cauda (tail latency) inexplicável causada por page faults, e consumo de RAM que "cresce sozinho" em aplicações long-running.

A verdade é que a maior parte dos desenvolvedores backend trata memória como uma caixa-preta: "aloco um objeto e o garbage collector cuida do resto". Mas essa abstração vaza. "E quando vaza — geralmente às 3h da manhã, com o pager tocando — quem entende o que acontece por baixo tem uma vantagem enorme".

Meu objetivo com este artigo é destrinchar como a memória virtual funciona no kernel Linux, partindo dos fundamentos teóricos (aqueles que aprendemos, ou deveríamos ter aprendido, na disciplina de Sistemas Operacionais) e conectando cada conceito com o que realmente acontece quando sua API responde a uma requisição.

Como sempre: estou escrevendo para consolidar meu próprio entendimento, mas se você tem interesse em ir além do CRUD, fique comigo.

Sumário da Parte I

Por que memória virtual existe?
A Hierarquia de Memória
Gerenciamento de Memória sem Abstração
A Abstração do Espaço de Endereçamento
Memória Virtual: os Fundamentos
A MMU e a Tradução de Endereços
Referências Bibliográficas

Por que memória virtual existe?

Antes de mergulhar em tabelas de páginas e MMUs, precisamos entender qual problema a memória virtual resolve. E, como quase tudo em sistemas operacionais, a resposta está na história.

Imagine um mundo sem memória virtual — que, aliás, foi o mundo real dos computadores até os anos 60. Nesse mundo, quando seu programa acessa o endereço 0x1000, ele acessa fisicamente a posição 0x1000 do chip de RAM. Simples, direto e cheio de problemas:

Sem proteção: qualquer processo pode ler e escrever na memória de qualquer outro processo. Um bug em um programa pode corromper outro. Um programa malicioso pode ler suas senhas.
Sem isolamento: dois programas compilados para rodar no endereço 0x1000 não podem coexistir.
Limitação física rígida: você não pode executar um programa que precise de mais memória do que a RAM instalada.
Fragmentação: conforme processos entram e saem, a memória vira um queijo suíço de buracos.

A memória virtual resolve todos esses problemas de uma vez, introduzindo uma camada de indireção entre os endereços que o programa usa (virtuais) e os endereços físicos da RAM:

"Todos os problemas em ciência da computação podem ser resolvidos com mais um nível de indireção." David Wheeler

A Hierarquia de Memória

Para entender por que o kernel se dá ao trabalho de gerenciar memória de forma tão elaborada, é preciso entender uma verdade desconfortável do hardware: memória rápida é cara e pequena; memória barata é grande e lenta. Não existe (ainda) uma tecnologia que seja simultaneamente rápida, barata e abundante.
não me diga que chip de DDR5 que voce comprou no Kabun é rápido :D

O resultado é uma hierarquia, onde cada nível troca velocidade por capacidade:

Repare na diferença brutal de escala: um acesso à RAM (~100 ns) é cerca de 300 vezes mais lento que um acesso a registrador. E um acesso a disco (HDD, ~10 ms) é 100.000 vezes mais lento que a RAM. Para colocar em perspectiva humana: se um acesso a registrador fosse 1 segundo, um acesso a disco seria equivalente a mais de um dia.

O Princípio da Localidade

O que torna essa hierarquia viável — em vez de um desastre de performance — é o princípio da localidade, uma observação empírica sobre como programas reais acessam memória:

Localidade temporal: se você acessou um endereço agora, provavelmente vai acessá-lo de novo em breve. Pense em uma variável de contador dentro de um loop, ou um objeto de configuração lido a cada requisição.
Localidade espacial: se você acessou um endereço, provavelmente vai acessar endereços vizinhos em breve. Pense em iterar sobre um array, ou percorrer os campos de uma struct.

É por causa da localidade que caches funcionam. Quando você acessa um byte da RAM, o hardware não traz apenas aquele byte — traz uma linha de cache inteira (tipicamente 64 bytes) para os níveis mais rápidos, apostando que você vai precisar dos vizinhos.

Por que isso importa para backend? Estruturas de dados que respeitam a localidade são dramaticamente mais rápidas. Um array contíguo (list do Python com tipos primitivos via NumPy, []T em Go, Array<T> em .NET) é percorrido muito mais rápido que uma lista encadeada espalhada pela heap, mesmo que ambos tenham complexidade $O(n)$. A constante escondida na notação Big-O é, muitas vezes, a hierarquia de memória se manifestando.

# Estes dois loops têm a MESMA complexidade O(n),
# mas performance radicalmente diferente por causa da localidade espacial.

import numpy as np

# Array contíguo: localidade espacial ótima, cache-friendly
dados_contiguos = np.arange(10_000_000)
soma = dados_contiguos.sum()   # o hardware faz prefetch das linhas de cache

# Objetos Python espalhados pela heap: cada acesso pode ser um cache miss
dados_espalhados = list(range(10_000_000))   # cada int é um objeto no heap
soma = sum(dados_espalhados)   # ~10-50x mais lento, entre outros motivos, por cache misses

Gerenciamento de Memória sem Abstração

Para valorizar a memória virtual, vale a pena entender como se vivia sem ela. Tanenbaum organiza essa evolução em etapas, e cada uma resolve uma limitação da anterior.

Monoprogramação

O modelo mais simples possível: um processo por vez. A memória é dividida entre o sistema operacional e o único programa do usuário. Quando você quer rodar outro programa, o atual precisa terminar.

┌──────────────────────┐  0xFFFF
│  Sistema Operacional │
├──────────────────────┤
│                      │
│  Programa do Usuário │
│                      │
└──────────────────────┘  0x0000

Isso é essencialmente o MS-DOS. Funciona, mas desperdiça CPU: enquanto o único processo espera I/O (disco, rede), a CPU fica ociosa. Para um servidor backend moderno, que passa boa parte do tempo esperando o banco de dados responder, isso seria catastrófico.

Multiprogramação com Partições Fixas

Para manter a CPU ocupada, precisamos de vários processos na memória ao mesmo tempo — quando um bloqueia em I/O, outro roda. A primeira tentativa foi dividir a memória em partições fixas:

┌──────────────────────┐
│  Sistema Operacional │
├──────────────────────┤
│  Partição 1 (8 MB)   │ ← Processo A
├──────────────────────┤
│  Partição 2 (4 MB)   │ ← Processo B
├──────────────────────┤
│  Partição 3 (4 MB)   │ ← livre
└──────────────────────┘

Aqui surge o primeiro fantasma que assombra o gerenciamento de memória até hoje: a fragmentação.

Fragmentação Interna vs Externa

Estes dois conceitos vão reaparecer o artigo inteiro, então vale fixá-los bem:

Fragmentação interna: acontece quando alocamos mais memória do que o necessário e o excesso, dentro do bloco alocado, é desperdiçado. Se um processo de 3 MB é colocado numa partição de 4 MB, aquele 1 MB restante fica preso e inutilizável — está "dentro" da partição, mas ninguém pode usá-lo.
Fragmentação externa: acontece quando há memória livre suficiente no total, mas ela está espalhada em pequenos buracos não-contíguos, nenhum grande o bastante para atender uma requisição. Você tem 10 MB livres, mas em pedaços de 1 MB, e chega um processo que precisa de 5 MB contíguos — não cabe, mesmo havendo espaço.

Fragmentação Externa:

┌────┬──────┬────┬──────┬────┐
│ P1 │ LIVRE│ P2 │ LIVRE│ P3 │
└────┴──────┴────┴──────┴────┘
        3MB          3MB

Total livre: 6 MB, mas o maior bloco contíguo é 3 MB.
Um processo de 5 MB não cabe, mesmo havendo 6 MB livres!

Esses conceitos não são história antiga — eles reaparecem no buddy allocator do kernel, na fragmentação da heap do seu processo, na fragmentação do Large Object Heap do .NET e na pressão de alocação do Go. Guarde-os.

Compactação de Memória

Uma solução para fragmentação externa é a compactação: mover todos os processos para um lado da memória, juntando os buracos livres em um único bloco grande.

Antes:  [P1][ livre ][P2][ livre ][P3]
Depois: [P1][P2][P3][      livre       ]

O problema? Compactação é caríssima. Mover gigabytes de RAM leva tempo e, durante a operação, o sistema praticamente para. Além disso, esbarramos num problema fundamental: se movemos um processo de lugar, todos os endereços que ele usa internamente mudam. Como o programa continua funcionando se o endereço 0x1000 agora é fisicamente 0x5000? Isso nos leva à necessidade de abstração.

A Abstração do Espaço de Endereçamento

O problema central de todos os modelos acima é que os programas usam endereços físicos diretamente. A solução é introduzir uma abstração: o espaço de endereçamento.

Um espaço de endereçamento é o conjunto de endereços que um processo pode usar para endereçar memória. A ideia genial é: cada processo tem seu próprio espaço de endereçamento, isolado dos demais, e os endereços que ele usa (virtuais) são traduzidos para endereços físicos por baixo dos panos.

Base e Limite: a proteção primitiva

A primeira implementação dessa ideia usava dois registradores de hardware: base e limite.

Quando um processo é carregado, o registrador base recebe o endereço físico onde ele começa.
Todo endereço que o programa gera é somado à base automaticamente pelo hardware.
O registrador limite guarda o tamanho do processo; qualquer acesso além dele gera uma falha (proteção).

Endereço virtual gerado pelo programa:  0x1000
Registrador base:                     + 0x5000
                                       ────────
Endereço físico real:                   0x6000   (se < limite, OK)

Isso resolve dois problemas de uma vez: relocação (o programa pode ser carregado em qualquer lugar, basta ajustar a base) e proteção (o limite impede que um processo acesse memória fora da sua região).

Relocação: estática vs dinâmica

Relocação estática: os endereços são ajustados uma vez, no momento da carga do programa. Simples, mas o processo não pode ser movido depois.
Relocação dinâmica: a tradução acontece a cada acesso, em tempo de execução, via hardware (base + limite, ou a MMU). É o que permite mover, fazer swap e compartilhar memória de forma flexível. É a abordagem dos sistemas modernos.

Swapping

Base e limite ainda esbarram num limite físico: e se a soma da memória de todos os processos exceder a RAM? A resposta clássica foi o swapping: mover processos inteiros da RAM para o disco quando não estão rodando, e trazê-los de volta quando necessário.

RAM:   [SO][ Processo A ][ Processo B ]
                              │  swap out
                              ▼
Disco: [ ............ Processo C ............ ]
                              │  swap in
                              ▼
RAM:   [SO][ Processo A ][ Processo C ]

O problema do swapping clássico é sua granularidade grosseira: mover um processo inteiro para o disco é lento e desperdiça banda se o processo só precisava de uma fração da sua memória. É aqui que a paginação e a memória virtual entram para revolucionar tudo — mas isso é o assunto central da próxima parte.

Memória Virtual: os Fundamentos

Chegamos ao conceito central. A memória virtual parte de uma constatação: raramente um programa precisa de toda a sua memória ao mesmo tempo.

A motivação: executar o impossível

A ideia original (Fotheringham, 1961) era permitir executar programas maiores que a memória física disponível. Em vez de exigir que o programa inteiro esteja na RAM, mantemos na memória apenas as partes que estão sendo usadas agora, deixando o resto no disco. Quando o programa acessa uma parte que não está na RAM, o kernel a traz do disco sob demanda.

O Working Set

Isso funciona por causa — de novo — do princípio da localidade. Peter Denning formalizou essa intuição no conceito de working set: o conjunto de páginas que um processo está ativamente usando em um dado intervalo de tempo. O working set costuma ser bem menor que o total de memória alocada pelo processo.

Exemplo backend concreto: uma API .NET pode ter 500 MB de assemblies, bibliotecas e código carregados, mas em um dado segundo, respondendo a requisições, ela toca apenas talvez 50 MB — o hot path do código, os objetos das requisições ativas, as conexões do pool. Esse é o working set. O resto pode ficar tranquilamente no disco (ou no page cache) até ser necessário.

Espaço de endereçamento virtual

Com memória virtual, cada processo enxerga um espaço de endereçamento contíguo e enorme — em sistemas de 64 bits, teoricamente $2^{64}$ bytes, na prática 48 ou 57 bits de endereçamento (falaremos disso na próxima parte). Esse espaço é independente do hardware físico: o processo não sabe (nem precisa saber) quanta RAM a máquina realmente tem, nem onde fisicamente suas páginas estão.

Repare que endereços virtuais contíguos podem mapear para frames físicos espalhados — e que dois processos podem ter o mesmo endereço virtual apontando para frames físicos diferentes. Essa é exatamente a mágica do isolamento.

A MMU e a Tradução de Endereços

Se a cada acesso à memória é preciso traduzir um endereço virtual para físico, essa tradução precisa ser rápida — rápida a ponto de acontecer em hardware, não em software. Quem faz isso é a MMU (Memory Management Unit), um componente do processador.

O fluxo, simplificado:

O núcleo da CPU gera um endereço virtual (por exemplo, ao executar mov rax, [0x00401000]).
A MMU intercepta esse endereço antes que ele chegue ao barramento de memória.
A MMU consulta a tabela de páginas (mantida pelo kernel) para descobrir qual frame físico corresponde àquela página virtual.
Se a tradução existe e é válida, a MMU emite o endereço físico correspondente para a RAM.
Se a página não está mapeada na memória física, a MMU dispara um page fault — uma interrupção que transfere o controle ao kernel para resolver a situação (buscar a página no disco, alocar uma nova página, ou matar o processo se o acesso for inválido).

Esse mecanismo é o coração de tudo o que veremos adiante. A tabela de páginas, o formato das suas entradas, como ela é organizada em múltiplos níveis, como a TLB acelera essa tradução, e o que exatamente acontece durante um page fault — tudo isso é o assunto das próximas partes.

Por ora, o essencial é ter internalizado a grande sacada: existe uma camada de tradução, feita em hardware, entre os endereços que seu programa usa e a memória física real. Toda a gestão de memória do Linux — proteção, isolamento, swap, copy-on-write, memory-mapped files, compartilhamento de bibliotecas — é construída sobre essa fundação.

Continua na Parte II, onde vamos abrir a tabela de páginas, entender a hierarquia de 4 e 5 níveis do Linux (PGD, PUD, PMD, PTE), o papel da TLB na performance e como a segmentação se encaixa nessa história.
:D

Conteúdo parcialmente gerado com auxílio de IA generativa (me ajudou a organizar tudo isso kkkk)

Referências Bibliográficas

Kernel Linux para Desenvolvedores Backend - Processos & Threads Parte IV

Alex Volnei Galante — Tue, 09 Jun 2026 15:02:40 +0000

Este artigo é a continuação da Parte III, recomendo começar por lá:
Kernel Linux para Desenvolvedores Backend — Processos & Threads Parte III

Sumário

Sequência de um Context Switch
Overhead de Context Switch: Custos Diretos e Indiretos
TLB Flush: Impacto na Performance
Cache Pollution: Efeitos em L1, L2 e L3
Reduzindo o Impacto de Context Switches
Conexão com Desenvolvimento Backend: .NET
- Thread Pool do .NET e Escalonamento do Kernel
- Task Parallel Library (TPL) e Cooperação com o Scheduler
- Async/Await e SynchronizationContext no Linux
- Exemplo Prático: Otimizando Aplicações ASP.NET Core em Containers
- CoreCLR e Interação com o Scheduler do Linux
- NUMA Awareness em Aplicações .NET
Conexão com Desenvolvimento Backend: Golang
- Goroutines vs Kernel Threads (M:N Threading Model)
- O Scheduler do Go Runtime e sua Relação com o Kernel
- GOMAXPROCS e CPU Affinity
- Análise de Performance: Blocking Syscalls e Goroutines
- Exemplo Prático: Microserviços Go e Tuning de Concorrência
Referências Bibliográficas

Sequência de um Context Switch

O context switch ocorre em resposta a diferentes triggers — preempção por timer, bloqueio em I/O, yield voluntário, ou chegada de processo de maior prioridade.

Thread A (executando)                Kernel                          Thread B (pronta)
        │                               │                                    │
        │   ← timer interrupt →         │                                    │
        │──────────────────────────────►│                                    │
        │                               │  1. Salva registradores de A       │
        │                               │     na kernel stack de A           │
        │                               │                                    │
        │                               │  2. Chama schedule()               │
        │                               │     → CFS seleciona B              │
        │                               │     (menor vruntime)               │
        │                               │                                    │
        │                               │  3. Chama context_switch()         │
        │                               │     a) switch_mm() — se processo   │
        │                               │        diferente: troca CR3        │
        │                               │        (page tables)               │
        │                               │     b) switch_to() — troca         │
        │                               │        kernel stack pointer        │
        │                               │        (RSP para stack de B)       │
        │                               │                                    │
        │                               │  4. Restaura registradores de B    │
        │                               │     da kernel stack de B           │
        │                               │                                    │
        │                               │  5. Retorna para userspace         │
        │                               │──────────────────────────────────► │
        │                               │                                    │
        │  (suspenso)                   │      (executando)                  │

No código do kernel Linux, a função central é context_switch() em kernel/sched/core.c:

/*
 * context_switch - troca para o novo contexto de MM e para
 * a nova thread (task_struct do processo que será executado).
 */
static __always_inline struct rq *
context_switch(struct rq *rq, struct task_struct *prev,
               struct task_struct *next)
{
    // Troca do espaço de endereçamento (memory descriptor)
    if (!next->mm) {                          // kernel thread
        next->active_mm = prev->active_mm;    // empresta mm do anterior
    } else {                                  // user process
        switch_mm(prev->active_mm, next->mm, next);  // troca page tables
    }

    // Troca do contexto de execução (registradores, stack)
    switch_to(prev, next, prev);

    return finish_task_switch(prev);
}

Overhead de Context Switch: Custos Diretos e Indiretos

O custo de um context switch vai muito além da simples operação de salvar/restaurar registradores.

Custos diretos (tempo gasto no switch em si)

Componente	Custo típico	Notas
Salvar/restaurar registradores gerais	~100-200ns	16 registradores de 64 bits
Salvar/restaurar FPU/SSE/AVX	~200-500ns	Depende do tamanho do estado SIMD
Chamada a `schedule()` + decisão	~200-500ns	Percorrer a red-black tree do CFS
`switch_mm()` (troca de CR3)	~100-300ns	Apenas entre processos diferentes
Overhead de kernel entry/exit	~100-200ns	Transição user↔kernel
Total direto (threads mesmo processo)	~0.5-1.5μs	Sem troca de address space
Total direto (processos diferentes)	~1-3μs	Com troca de address space

Custos indiretos (efeitos colaterais — frequentemente maiores que custos diretos)

Context Switch: Custos Indiretos

┌────────────────────────────────────────────────────────────────┐
│                                                                │
│  ┌──────────────┐     ┌───────────────┐     ┌───────────────┐  │
│  │  TLB Flush   │     │Cache Pollution│     │Pipeline Flush │  │
│  │              │     │               │     │               │  │
│  │ Custo: ~5μs  │     │ Custo: ~10μs  │     │ Custo: ~1μs   │  │
│  │ (warm-up)    │     │ (warm-up)     │     │ (imediato)    │  │
│  └──────────────┘     └───────────────┘     └───────────────┘  │
│         │                    │                    │            │
│         ▼                    ▼                    ▼            │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ Custo TOTAL efetivo: 5-50μs (dependendo do working set) │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                │
└────────────────────────────────────────────────────────────────┘

Os custos indiretos podem ser 10-50x maiores que os custos diretos, porque refletem o tempo necessário para "aquecer" as caches depois que o novo processo começa a executar.

TLB Flush: Impacto na Performance

O TLB (Translation Lookaside Buffer) é um cache de traduções de endereços virtuais para físicos. Como cada processo tem seu próprio espaço de endereçamento (page tables diferentes), as entradas do TLB de um processo são inválidas para outro.

O problema

Antes do context switch:
TLB (processo A):
┌────────────────────────────────────┐
│ VPN 0x7f0001 → PFN 0x3A2 (hit!)    │  ← acesso rápido (~1 ciclo)
│ VPN 0x7f0002 → PFN 0x1B5 (hit!)    │
│ VPN 0x400000 → PFN 0x089 (hit!)    │
│ ... (centenas de entradas)         │
└────────────────────────────────────┘

Após context switch para processo B (TLB flush):
TLB:
┌────────────────────────────────────┐
│ (vazio)                            │  ← TODOS os acessos são miss
│ (vazio)                            │     cada miss = page table walk
│ (vazio)                            │     (~10-100 ciclos por miss)
│ ...                                │
└────────────────────────────────────┘

Processo B precisa "aquecer" o TLB:
Acesso 1: VPN 0x500000 → TLB miss → page walk → PFN 0x2C1 (lento!)
Acesso 2: VPN 0x500001 → TLB miss → page walk → PFN 0x2C2 (lento!)
...
Após ~100-1000 acessos: TLB aquecido novamente

Impacto quantitativo

TLB L1 (dTLB/iTLB): ~64-128 entradas, miss penalty ~7 ciclos (L2 TLB hit)
TLB L2 (STLB): ~512-2048 entradas, miss penalty ~20-100 ciclos (page walk)
Para um working set de 100MB em páginas de 4KB: 25.600 páginas — impossível caber no TLB

# Medindo TLB misses com perf
$ perf stat -e dTLB-load-misses,dTLB-loads,iTLB-load-misses \
    -p <pid> sleep 5

Performance counter stats for process 'python3':
         1,234,567  dTLB-load-misses    # 0.15% of all dTLB loads
       823,456,789  dTLB-loads
           123,456  iTLB-load-misses

# TLB miss rate alto (>1%) indica impacto significativo de context switches
# ou working set muito grande

Mitigações

PCID (Process-Context Identifiers): Processadores modernos (Haswell+) suportam tags no TLB que identificam a qual processo cada entrada pertence. Isso permite manter entradas de múltiplos processos no TLB simultaneamente, evitando flush completo.

TLB com PCID:
┌────────────────────────────────────────────┐
│ PCID=1 VPN 0x7f0001 → PFN 0x3A2 (proc A)   │  ← mantido!
│ PCID=1 VPN 0x7f0002 → PFN 0x1B5 (proc A)   │  ← mantido!
│ PCID=2 VPN 0x500000 → PFN 0x2C1 (proc B)   │  ← novo
│ PCID=2 VPN 0x500001 → PFN 0x2C2 (proc B)   │  ← novo
└────────────────────────────────────────────┘
Quando A volta a executar: TLB hits imediatos!

Huge pages (2MB/1GB): Reduzem o número de entradas TLB necessárias. Com páginas de 2MB, 100MB de working set requer apenas 50 entradas TLB (vs 25.600 com 4KB).
Thread affinity: Manter threads no mesmo core reduz TLB pressure — threads do mesmo processo compartilham o address space e portanto as mesmas entradas TLB.

Implicação prática: No Linux com PCID habilitado (default desde kernel 4.14+), o custo de TLB flush em context switches é significativamente reduzido. Porém, KPTI (Kernel Page Table Isolation — mitigação para Meltdown) requer flush parcial de TLB em cada syscall, adicionando overhead (~5-10%) mesmo sem context switch.

Cache Pollution: Efeitos em L1, L2 e L3

O segundo grande custo indireto é a poluição de cache. Quando um processo é escalonado, ele começa a acessar suas regiões de memória — que provavelmente não estão nos caches — expulsando dados do processo anterior.

Hierarquia de cache e impacto

Hierarquia de Cache (servidor típico):
┌─────────────────────────────────────────────────────────────┐
│ L1 Cache (por core)                                         │
│   ├── L1d (dados): 32-48KB, ~4 ciclos latência              │
│   └── L1i (instruções): 32-48KB, ~4 ciclos                  │
│   → Context switch: 100% invalidado (working set diferente) │
├─────────────────────────────────────────────────────────────┤
│ L2 Cache (por core)                                         │
│   └── Unified: 256KB-1.25MB, ~12 ciclos                     │
│   → Context switch: 80-100% invalidado                      │
├─────────────────────────────────────────────────────────────┤
│ L3 Cache (compartilhado entre cores)                        │
│   └── Shared: 16-64MB, ~30-40 ciclos                        │
│   → Context switch no mesmo core: impacto em L3 parcial     │
│   → Migração entre cores: impacto maior                     │
└─────────────────────────────────────────────────────────────┘

Cache miss penalties:
  L1 hit:  ~4 ciclos  (~1.5ns @ 3GHz)
  L2 hit:  ~12 ciclos (~4ns)
  L3 hit:  ~30-40 ciclos (~12ns)
  RAM:     ~200-300 ciclos (~100ns)  ← 60-70x mais lento que L1!

Cenário: API server com context switches frequentes

Servidor com 16 workers competindo por 8 cores:

Worker A (executando query handler):
  - Hot data em L1/L2: connection pool struct, query buffer, hash map
  - Working set: ~200KB em L2

  ← context switch (preempção por timer) →

Worker B começa a executar:
  - Seu working set (~200KB) substitui dados de A no L2
  - Cada acesso de B é um L2 miss inicialmente (~12 ciclos → RAM ~200 ciclos)

  ← context switch (B bloqueia em I/O) →

Worker A retoma:
  - Seus dados NÃO estão mais no L2!
  - Período de "cache warm-up": ~1000-5000 cache misses
  - Overhead efetivo: 1000 × 100ns = ~100μs de penalidade

Impacto em latência da API:
  - Se timer tick = 4ms e handler leva ~2ms
  - ~1 context switch por request em média
  - Cache warm-up adiciona ~50-100μs por request
  - Em p99: múltiplos context switches → +200-500μs

Medindo cache pollution

# Cache misses por context switch
$ perf stat -e cache-misses,cache-references,context-switches \
    -p <pid> sleep 10

Performance counter stats:
        5,234,567  cache-misses        # 3.2% of cache references
      163,580,000  cache-references
           12,456  context-switches

# Cache misses por context switch: 5,234,567 / 12,456 ≈ 420 misses/switch
# Custo estimado: 420 × 100ns = 42μs de warm-up por switch

Reduzindo o Impacto de Context Switches

Para aplicações backend de alta performance, minimizar context switches (ou seu impacto) é uma otimização significativa:

Estratégias de Mitigação:

1. REDUZIR número de context switches:
   ├── Dimensionar workers = cores (evitar oversubscription)
   ├── Usar async I/O (epoll/io_uring) ao invés de thread-per-connection
   ├── Batch processing: processar múltiplos items antes de ceder CPU
   └── Aumentar timeslice para workloads batch (nice, SCHED_BATCH)

2. REDUZIR custo de cada context switch:
   ├── CPU affinity (taskset/sched_setaffinity): manter thread no mesmo core
   ├── NUMA-aware allocation: memória próxima ao core
   ├── Huge pages: menos TLB entries necessárias
   └── Manter working set compacto (cabe no L2/L3)

3. EVITAR migração entre cores:
   ├── cgroups cpuset: pinning de processos a cores específicos
   ├── isolcpus: reservar cores exclusivos para a aplicação
   └── GOMAXPROCS/worker count = cores no cpuset

# Pinning de processo a cores específicos
$ taskset -c 0-3 python3 app.py        # restringe aos cores 0-3

# Isolando cores no boot (grub)
# GRUB_CMDLINE_LINUX="isolcpus=4-7"    # cores 4-7 isolados do scheduler geral

# Verificando context switches de um processo
$ pidstat -w -p <pid> 1
Linux 5.15.0 (server)    05/14/2026
09:00:01 AM   PID   cswch/s nvcswch/s  Command
09:00:02 AM  1350    152.00     12.00  python3
              ↑ voluntary   ↑ involuntary (preempted)

Regra prática para backend:

Se nvcswch/s (involuntary) é alto → oversubscription de CPU (mais threads que cores)

Se cswch/s (voluntary) é alto → normal para I/O-bound (bloqueia em syscalls)

Se ambos são altos → redesenhe a arquitetura (async I/O, menos workers, ou CPU affinity)

Conexão com Desenvolvimento Backend: .NET

O .NET runtime (CoreCLR) no Linux é um dos exemplos mais sofisticados de como um runtime gerenciado interage com o escalonador do kernel. Diferente do Python (limitado pelo GIL) ou do Go (que implementa seu próprio scheduler M:N), o .NET adota um modelo 1:1 onde cada thread gerenciada mapeia diretamente para uma kernel thread — mas adiciona uma camada de abstração poderosa: o ThreadPool e o Task Parallel Library (TPL).

Thread Pool do .NET e Escalonamento do Kernel

O ThreadPool do .NET é o coração da execução assíncrona em aplicações ASP.NET Core. Ele gerencia um conjunto de kernel threads que executam work items enfileirados — incluindo continuações de async/await, timers, e I/O completion callbacks.

Arquitetura do ThreadPool

Aplicação ASP.NET Core
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   Request 1 ──┐     Request 2 ──┐     Request 3 ──┐             │
│               ▼                  ▼                  ▼           │
│   ┌─────────────────────────────────────────────────────┐       │
│   │              Global Work Queue                      │       │
│   │  [Task A] → [Task B] → [Task C] → [Task D] → ...    │       │
│   └────────────────────────┬────────────────────────────┘       │
│                            │                                    │
│   ┌────────────────────────┼────────────────────────────┐       │
│   │         ThreadPool     │                            │       │
│   │  ┌──────────┐  ┌──────┴─────┐  ┌──────────┐         │       │
│   │  │ Worker 1 │  │  Worker 2  │  │ Worker 3 │  ...    │       │
│   │  │(stealing)│  │(executing) │  │(waiting) │         │       │
│   │  └────┬─────┘  └─────┬──────┘  └────┬─────┘         │       │
│   │       │Local Q        │Local Q       │Local Q       │       │
│   └───────┼───────────────┼──────────────┼──────────────┘       │
│           │               │              │                      │
├───────────┼───────────────┼──────────────┼──────────────────────┤
│   Kernel  ▼               ▼              ▼                      │
│   ┌──────────┐     ┌──────────┐   ┌──────────┐                  │
│   │  KThread │     │  KThread │   │  KThread │                  │
│   │  (core 0)│     │  (core 1)│   │  (core 2)│                  │
│   └──────────┘     └──────────┘   └──────────┘                  │
│              CFS Scheduler (kernel)                             │
└─────────────────────────────────────────────────────────────────┘

Hill Climbing Algorithm

O ThreadPool do .NET usa um algoritmo de hill climbing para ajustar dinamicamente o número de threads. Ao contrário de pools estáticos (como Gunicorn workers), o .NET ThreadPool monitora o throughput e adiciona/remove threads para maximizá-lo:

Hill Climbing: Ajuste dinâmico de threads

Throughput
    ▲
    │         ╭──── ponto ótimo
    │        ╱│╲
    │       ╱ │ ╲
    │      ╱  │  ╲         ← mais threads = mais context switches
    │     ╱   │   ╲            = menos throughput
    │    ╱    │    ╲
    │   ╱     │     ╲
    │──╱──────┼──────╲────────►
    │         │              Número de threads
    │    under-    over-
    │  subscribed  subscribed

Comportamento:
1. Começa com Environment.ProcessorCount threads
2. Adiciona 1 thread a cada 500ms se work items estão enfileirados
3. Mede throughput (work items completed/sec)
4. Se throughput subiu → continua adicionando
5. Se throughput caiu → remove thread (oversubscription detectada)

Interação com o Kernel Scheduler

Cada worker thread do ThreadPool é uma kernel thread real (clone() com CLONE_VM | CLONE_FILES | CLONE_SIGHAND). Isso significa que:

O CFS escalona cada worker independentemente — se você tem 8 workers em 4 cores, o CFS garante distribuição justa
Context switches entre workers são reais — com custo de ~1-2μs (threads do mesmo processo, sem TLB flush)
Involuntary preemption ocorre — se um handler de request é CPU-bound, será preemptado após seu timeslice

# Monitorando ThreadPool via dotnet-counters
$ dotnet-counters monitor --process-id <pid> System.Runtime

[System.Runtime]
    # of Active Timers                          12
    ThreadPool Completed Work Item Count    1,847,293
    ThreadPool Queue Length                       0     ← 0 = saudável
    ThreadPool Thread Count                     16     ← threads ativas
    Monitor Lock Contention Count              234

# Se Queue Length > 0 persistentemente:
# → ThreadPool está saturado
# → Requests estão esperando por thread disponível
# → Considere: mais threads, async I/O, ou otimizar handlers

Implicação prática: O ThreadPool Queue Length é o equivalente .NET ao "load average" da aplicação. Se consistentemente > 0, sua aplicação está thread-starved. Possíveis causas: sync-over-async (bloqueando threads com .Result ou .Wait()), thread pool exhaustion por I/O bloqueante, ou handlers CPU-bound longos.

Task Parallel Library (TPL) e Cooperação com o Scheduler

O TPL (System.Threading.Tasks) é a abstração de alto nível que o .NET oferece sobre o ThreadPool. Quando você escreve Task.Run(...) ou usa async/await, o TPL decide quando e onde executar o código.

Work Stealing e Localidade de Cache

O ThreadPool do .NET implementa work stealing — cada worker thread tem uma fila local (lock-free deque). Quando sua fila esvazia, a thread "rouba" trabalho da fila de outra thread:

Work Stealing:

Worker 1 (core 0)        Worker 2 (core 1)        Worker 3 (core 2)
┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│ Local Queue  │         │ Local Queue  │         │ Local Queue  │
│ [T1][T2][T3] │         │ [T4][T5]     │         │ (vazia)      │
└──────────────┘         └──────────────┘         └──────┬───────┘
                                                         │
                                                    steal│from Worker 1
                                                         │
                                                         ▼
                                                    executa T3

Impacto no kernel scheduler:

Work stealing mantém todas as threads ocupadas → menos idle time → melhor utilização de CPU
Porém, roubar trabalho de outra thread pode significar processar dados que estão no cache de outro core → cache misses
O .NET tenta minimizar isso mantendo continuações (await) na mesma thread que iniciou a operação

Parallel.ForEach e Partitioning

// Processamento paralelo de batch
await Parallel.ForEachAsync(items, 
    new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount },
    async (item, ct) => 
    {
        await ProcessItemAsync(item, ct);
    });

O MaxDegreeOfParallelism = Environment.ProcessorCount é a configuração ideal para workloads CPU-bound — evita oversubscription. Para I/O-bound, pode ser maior (as threads bloqueiam em I/O e o kernel escalona outras).

Async/Await e SynchronizationContext no Linux

O modelo async/await do .NET é fundamentalmente diferente de threads — é concorrência cooperativa sobre o ThreadPool:

async Task<Response> HandleRequest(Request req)
{
    var data = await db.QueryAsync(sql);    // ← libera a thread!
    var result = Transform(data);            // ← pode executar em OUTRA thread
    await cache.SetAsync(key, result);       // ← libera novamente
    return new Response(result);
}

Timeline de uma thread do ThreadPool:

Thread 1: |─handle req A─|await|─handle req B─|await|─continue A─|await|...
                              │                          ↑
                              └── thread devolvida ──────┘
                                  ao pool (kernel thread
                                  disponível para outro trabalho)

SynchronizationContext no Linux

No ASP.NET Core (ao contrário do WPF/WinForms), não há SynchronizationContext. Isso significa:

Continuações após await podem executar em qualquer thread do pool
Não há overhead de marshaling para uma thread específica
Não há risco de deadlock por contexto de sincronização

ASP.NET Core (sem SynchronizationContext):

Thread 1: |── req A: antes do await ──|   |── req B: continuação ──|
Thread 2: |── req B: antes do await ──|   |── req A: continuação ──|
                                              ↑
                                     continuação de A executa em Thread 2
                                     (qualquer thread disponível)

vs WPF/WinForms (com SynchronizationContext):

Thread 1 (UI): |── antes await ──|── continuação ──|  ← SEMPRE na UI thread
                                        ↑
                                   marshaled de volta (overhead + possível deadlock)

Implicação para o kernel: Sem SynchronizationContext, as continuações de await são enfileiradas no ThreadPool global. O kernel vê apenas threads do pool pegando trabalho — não há affinity forçada. Isso é bom para throughput (qualquer core pode executar qualquer continuação), mas pode causar mais cache misses (dados de um request processados em cores diferentes).

Async I/O no Linux: epoll sob o capô

Quando você faz await httpClient.GetAsync(url) no Linux, o .NET usa epoll para I/O assíncrono:

Sequência de async I/O no .NET no Linux:

1. Código C#: await socket.ReadAsync(buffer)
2. CoreCLR: registra fd no epoll_ctl(EPOLL_CTL_ADD)
3. Thread devolvida ao ThreadPool
4. Kernel: dados chegam no socket
5. epoll_wait() retorna (na I/O completion thread)
6. CoreCLR: enfileira continuação no ThreadPool
7. Worker thread pega a continuação e executa o código após await

┌─────────────────────────────────────────────────┐
│ .NET I/O Thread (dedicada)                      │
│                                                 │
│   loop {                                        │
│     events = epoll_wait(epfd, ...)              │
│     for event in events {                       │
│       queue_continuation(event.callback)        │
│     }                                           │
│   }                                             │
│                                                 │
└─────────────────────────────────────────────────┘
         │
         ▼ enfileira no ThreadPool
┌─────────────────────────────────────────────────┐
│ Worker Threads (executam continuações)          │
│  Thread 1: executa callback de socket read      │
│  Thread 2: executa callback de DB query         │
│  Thread 3: executa callback de HTTP response    │
└─────────────────────────────────────────────────┘

O .NET mantém 1-2 threads dedicadas chamando epoll_wait() — essas são as I/O completion threads (diferentes das worker threads). Elas nunca executam código do usuário diretamente — apenas enfileiram continuações.

Exemplo Prático: Otimizando Aplicações ASP.NET Core em Containers

Cenário: API em Kubernetes com latência alta no p99

Ambiente:
- Kubernetes pod com limits: 4 CPU, 8GB RAM
- ASP.NET Core 8.0 API
- ~2000 req/s
- p50: 15ms, p95: 45ms, p99: 350ms (!) ← problema

Diagnóstico:
$ dotnet-counters monitor --process-id 1 System.Runtime
    ThreadPool Thread Count:     87        ← muito alto para 4 cores!
    ThreadPool Queue Length:     12        ← work items esperando
    Monitor Lock Contention Count: 4521   ← contenção de locks

$ pidstat -w -p 1 1
    cswch/s: 8500    nvcswch/s: 2100      ← muitos involuntary switches!

Problema identificado: Thread pool cresceu demais (87 threads para 4 cores) → oversubscription severa → context switches excessivos → cache pollution → latência alta no p99.

Causas comuns:

Chamadas síncronas bloqueantes (sync-over-async)
Lock contention forçando threads a bloquear
ThreadPool adicionando threads porque as existentes estão bloqueadas

Solução 1: Eliminar sync-over-async

// ❌ ERRADO: bloqueia thread do pool esperando resultado
public Response GetData()
{
    var result = _httpClient.GetAsync(url).Result;  // BLOQUEIA a thread!
    return Process(result);
}

// ✅ CORRETO: libera thread durante I/O
public async Task<Response> GetDataAsync()
{
    var result = await _httpClient.GetAsync(url);   // libera thread
    return Process(result);
}

Cada .Result ou .Wait() bloqueia uma thread do pool. O hill climbing detecta threads bloqueadas e injeta novas → mais threads → mais context switches → degradação exponencial.

Solução 2: Limitar ThreadPool em containers

// Program.cs — configuração para containers
// Limita threads ao número de cores disponíveis no cgroup

// Para workloads I/O-bound (maioria das APIs):
ThreadPool.SetMinThreads(
    workerThreads: Environment.ProcessorCount * 2,
    completionPortThreads: Environment.ProcessorCount);

ThreadPool.SetMaxThreads(
    workerThreads: Environment.ProcessorCount * 4,  // cap em 4x cores
    completionPortThreads: Environment.ProcessorCount * 2);

# Variáveis de ambiente para tuning em containers
DOTNET_ThreadPool_UnfairSemaphoreSpinLimit=0  # reduz spin-wait (bom para containers)
DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS=1  # reduz context switches para I/O

Solução 3: CPU affinity via cgroups

# Kubernetes pod spec com CPU pinning
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: api
    resources:
      requests:
        cpu: "4"          # garante 4 cores dedicados
        memory: "8Gi"
      limits:
        cpu: "4"          # mesmo valor = guaranteed QoS = CPU pinning
        memory: "8Gi"

Quando requests.cpu == limits.cpu no Kubernetes, o kubelet configura o cgroup com cpuset — cores exclusivos. Isso elimina migração entre cores e reduz cache pollution.

Resultado após otimização

Antes:                          Depois:
ThreadPool Threads: 87          ThreadPool Threads: 12
Queue Length: 12                Queue Length: 0
Context switches: 8500/s        Context switches: 1200/s
p50: 15ms                       p50: 12ms
p95: 45ms                       p95: 25ms
p99: 350ms                      p99: 55ms  ← 6.4x melhor!

CoreCLR e Interação com o Scheduler do Linux

O CoreCLR (runtime do .NET no Linux) interage com o kernel scheduler de várias formas:

GC (Garbage Collector) e Escalonamento

O GC do .NET pode causar stop-the-world pauses que afetam o escalonamento:

Server GC (recomendado para APIs):
- 1 GC thread por core (dedicadas)
- Durante GC: TODAS as threads da aplicação são suspensas
- Duração típica: 1-50ms (Gen2 full GC pode ser > 100ms)

Timeline durante GC:
Core 0: |── app ──|── GC ──|── app ──|
Core 1: |── app ──|── GC ──|── app ──|
Core 2: |── app ──|── GC ──|── app ──|
Core 3: |── app ──|── GC ──|── app ──|
                   ↑ todas as cores param
                     (visible no perf como pause)

Workstation GC (recomendado para containers com 1-2 cores):
- 1 GC thread compartilhada
- Menos overhead de memória
- Pausas maiores mas menos impacto em poucos cores

# Configuração de GC para containers
DOTNET_gcServer=1                    # Server GC (se >= 2 cores)
DOTNET_GCHeapCount=4                 # Limitar GC heaps (match com cores)
DOTNET_GCConserveMemory=5            # 1-9: trade-off memória vs throughput

Thread Suspension e Sinais

O CoreCLR usa sinais POSIX (SIGUSR1, SIGUSR2) para suspender threads durante GC:

GC thread envia SIGUSR2 para todas as threads gerenciadas
Signal handler em cada thread salva seu estado e sinaliza "safe point"
GC executa (coleta, compacta)
Threads são resumidas

Esse mecanismo interage com o kernel scheduler — se uma thread está em TASK_INTERRUPTIBLE (esperando I/O), o sinal a acorda imediatamente para que o GC possa prosseguir.

NUMA Awareness em Aplicações .NET

Em servidores multi-socket (2+ CPUs físicas), a arquitetura NUMA (Non-Uniform Memory Access) significa que acessar memória "local" (no mesmo nó) é significativamente mais rápido que memória "remota" (em outro nó):

Servidor dual-socket NUMA:

┌─────────────────────────┐    ┌─────────────────────────┐
│       NUMA Node 0       │    │       NUMA Node 1       │
│                         │    │                         │
│  CPU 0-7 (8 cores)      │    │  CPU 8-15 (8 cores)     │
│  RAM local: 64GB        │    │  RAM local: 64GB        │
│  Latência local: ~100ns │    │  Latência local: ~100ns │
│                         │    │                         │
└────────────┬────────────┘    └────────────┬────────────┘
             │                              │
             └────── QPI/UPI link ──────────┘
                   Latência remota: ~150-300ns
                   (1.5-3x mais lento!)

.NET e NUMA

O CoreCLR tem awareness básico de NUMA:

Server GC cria um GC heap por NUMA node (não por core)
ThreadPool distribui threads entre nodes
Alocações são feitas preferencialmente na memória local ao core que está executando

// Verificando topologia NUMA em .NET
Console.WriteLine($"Processor Count: {Environment.ProcessorCount}");
// Em NUMA: retorna total de cores em todos os nodes

// Para workloads NUMA-sensitive, use CPU affinity:
// Exemplo: restringir processo a um único NUMA node

# Executando aplicação .NET em NUMA node específico
$ numactl --cpunodebind=0 --membind=0 dotnet MyApi.dll

# Verificando distribuição de memória NUMA
$ numastat -p <pid>
Per-node process memory usage (in MBs)
                 Node 0   Node 1    Total
                 ------   ------   ------
Heap               512       48      560    ← idealmente tudo em Node 0
Stack               16        2       18
Private            128       12      140

# Se há memória significativa no node "errado":
# → alocação ocorreu em thread executando no outro node
# → threadpool scheduling está causando acesso remoto

Configuração NUMA para .NET em produção

# Opção 1: Processos separados por NUMA node
# (Melhor isolamento, mais simples)
$ numactl --cpunodebind=0 --membind=0 dotnet MyApi.dll --urls http://+:5000
$ numactl --cpunodebind=1 --membind=1 dotnet MyApi.dll --urls http://+:5001
# Load balancer distribui entre as duas instâncias

# Opção 2: Kubernetes com topology-aware scheduling
# topology.kubernetes.io/zone anotações para NUMA-aware placement

# Opção 3: Configuração de GC NUMA-aware
DOTNET_gcServer=1
DOTNET_GCHeapCount=8        # heaps = cores por NUMA node
DOTNET_GCNoAffinitize=0     # permitir GC affinitizar threads
DOTNET_GCHeapAffinitizeMask=0xFF  # cores 0-7 (Node 0)

Regra prática para .NET e NUMA:

Servidores single-socket (maioria na cloud): NUMA não é preocupação

Servidores dual-socket (bare metal, databases): Configure numactl ou use instâncias separadas por node

Containers em Kubernetes: Use topologySpreadConstraints e resource limits que se alinham com NUMA boundaries

Monitore com numastat e perf stat -e node-load-misses — se acesso remoto > 10%, otimize

Conexão com Desenvolvimento Backend: Golang

O Go é único entre as linguagens backend mainstream por implementar um verdadeiro modelo M:N de threading — goroutines (user-level threads) são multiplexadas sobre um número menor de kernel threads pelo runtime scheduler. Essa arquitetura permite criar milhões de unidades de concorrência com overhead mínimo, mas a interação com o kernel scheduler do Linux introduz nuances que todo desenvolvedor Go precisa compreender.

Goroutines vs Kernel Threads (M:N Threading Model)

Uma goroutine não é uma thread do sistema operacional. É uma unidade de execução gerenciada pelo Go runtime, com custo de criação e memória drasticamente menor:

Característica	Goroutine	Kernel Thread (OS Thread)
Stack inicial	~2KB (cresce dinamicamente até 1GB)	~2-8MB (fixa, definida por `ulimit -s`)
Custo de criação	~0.3μs	~10-50μs
Context switch	~0.1-0.2μs (userspace)	~1-3μs (kernel)
Quantidade típica	Milhares a milhões	Centenas a baixos milhares
Escalonamento	Go runtime scheduler	Kernel CFS
Preempção	Cooperativa + async (Go 1.14+)	Preemptiva (timer interrupt)

Modelo M:N do Go:

                    Userspace (Go runtime)
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   G1  G2  G3  G4  G5  G6  G7  G8 ... G100000                    │
│   │   │   │   │   │   │   │   │                                 │
│   └─┬─┘   │   └─┬─┘   │   └─┬─┘                                 │
│     │     │     │     │     │      ← goroutines (user threads)  │
│     ▼     ▼     ▼     ▼     ▼                                   │
│   ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐                                 │
│   │P0 │ │P1 │ │P2 │ │P3 │ │P4 │   ← P (Logical Processors)      │
│   │LRQ│ │LRQ│ │LRQ│ │LRQ│ │LRQ│     cada P tem local run queue  │
│   └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘                                 │
│     │     │     │     │     │                                   │
│     ▼     ▼     ▼     ▼     ▼                                   │
│   ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐                                 │
│   │M0 │ │M1 │ │M2 │ │M3 │ │M4 │   ← M (OS Threads/Machines)     │
│   └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘     mapeiam para task_struct    │
├─────┼─────┼─────┼─────┼─────┼───────────────────────────────────┤
│     ▼     ▼     ▼     ▼     ▼         Kernel                    │
│   KT0   KT1   KT2   KT3   KT4        (kernel threads)           │
│   ┌─────────────────────────────┐                               │
│   │     CFS Scheduler           │                               │
│   └─────────────────────────────┘                               │
└─────────────────────────────────────────────────────────────────┘

Terminologia:
  G = Goroutine (unidade de execução leve)
  P = Processor (contexto lógico, contém run queue local)
  M = Machine (kernel thread real, escalonada pelo CFS)

Relação: muitos G → poucos P → poucos M → cores do hardware

A chave do modelo é: G (goroutines) >> P (processors) >= M (OS threads) ≈ cores

O Scheduler do Go Runtime e sua Relação com o Kernel

O Go scheduler opera em userspace, executando dentro de cada M (OS thread). Ele toma decisões de escalonamento sem envolver o kernel — o que elimina o overhead de syscalls para context switches entre goroutines.

Componentes do scheduler (GMP model)

Anatomia de um P (Logical Processor):

P (Processor)
├── Local Run Queue (LRQ)
│   └── [G5] → [G12] → [G31] → ...    ← fila FIFO de goroutines prontas
├── Current G                            ← goroutine em execução
├── mcache                               ← cache de memória por-P (performance)
├── Timer heap                           ← goroutines dormindo (time.Sleep, etc.)
└── Runnext                              ← próxima G a executar (fast path)

Global Run Queue (GRQ):
└── [G99] → [G200] → [G345] → ...      ← overflow das LRQs, acessada com lock

Idle M list:
└── M5 → M6 → M7 → ...                 ← threads do kernel ociosas

Quando o Go scheduler roda (scheduling points)

O scheduler é invocado (em userspace) em pontos específicos:

Pontos de escalonamento do Go:

1. Chamada a função (function prologue)
   ├── Verifica se stack precisa crescer
   └── Verifica preemption flag (Go 1.14+: sinal SIGURG)

2. Channel operations
   ├── ch <- value (send bloqueante)
   └── <-ch (receive bloqueante)

3. Blocking syscalls
   ├── file I/O, network I/O (em raw syscall)
   └── M é liberado, P migra para outro M

4. runtime.Gosched()
   └── yield explícito (raro em código moderno)

5. Garbage Collection
   ├── STW (stop-the-world) phases
   └── GC assist (goroutine ajuda no marking)

6. time.Sleep / timer expiration
   └── Goroutine vai para timer heap do P

7. sync primitives
   ├── sync.Mutex.Lock() (quando contended)
   └── sync.WaitGroup.Wait()

Interação com o kernel: blocking syscalls

O aspecto mais importante da relação Go runtime ↔ kernel é o tratamento de syscalls bloqueantes:

Cenário: goroutine G1 faz syscall bloqueante (ex: file read)

ANTES da syscall:
  P0 ←→ M0: executando G1
  P0.LRQ: [G2, G3, G4]   ← goroutines esperando

DURANTE a syscall:
  1. Go runtime detecta que G1 vai bloquear
  2. P0 se DESACOPLA de M0
  3. P0 se ACOPLA a M1 (um M idle, ou cria novo M)
  4. M1 começa a executar G2 da LRQ de P0
  5. M0 continua bloqueado no kernel com G1

  P0 ←→ M1: executando G2       ← P continua produtivo!
  M0: bloqueado em read() com G1 ← kernel thread bloqueada

APÓS a syscall retornar:
  1. M0 acorda com G1
  2. Tenta re-adquirir P0 (ou qualquer P idle)
  3. Se consegue: G1 volta a executar
  4. Se não: G1 vai para Global Run Queue
  5. M0 vai para idle list

Timeline:
M0: |─── G1 ───|── read() bloqueante ──|── G1 retoma ──|
M1:             |── G2 ──|── G3 ──|── G4 ──|
                ↑
         P migra para M1 (latência ~μs)

Esse mecanismo é o que permite ao Go ter I/O "assíncrono" sem async/await — do ponto de vista do programador, o código é síncrono e sequencial, mas o runtime garante que outras goroutines continuam executando.

Network poller (netpoller)

Para I/O de rede, o Go usa um mecanismo diferente — o netpoller, baseado em epoll no Linux:

Network I/O (não bloqueia M):

1. goroutine chama conn.Read()
2. Runtime: setsockopt(fd, O_NONBLOCK)
3. Runtime: tenta read() → EAGAIN (nada disponível)
4. Runtime: registra fd em epoll + parks goroutine
5. Goroutine sai do P (não ocupa M!)
6. P executa outras goroutines

... dados chegam no socket ...

7. Sysmon thread (ou outro M): epoll_wait() detecta fd ready
8. Goroutine é colocada de volta na run queue
9. Goroutine retoma conn.Read() → dados disponíveis

Diferença crucial:
  - File I/O: BLOQUEIA o M (kernel thread fica presa)
  - Network I/O: NÃO bloqueia M (epoll + park/unpark)

Implicação:
  - 100k goroutines fazendo network I/O → ~GOMAXPROCS OS threads
  - 100k goroutines fazendo file I/O → pode criar 100k OS threads!

GOMAXPROCS e CPU Affinity

GOMAXPROCS controla o número de P's (processors lógicos) — efetivamente o paralelismo máximo de execução de goroutines em Go code (não syscalls).

GOMAXPROCS e sua relação com o hardware:

GOMAXPROCS=1:
  Core 0: |─G1─|─G2─|─G1─|─G3─|─G2─|   ← sem paralelismo Go
  Core 1: (idle para Go)                  ← pode ter M's em syscall
  → Útil para: debugging, eliminação de race conditions

GOMAXPROCS=4 (em máquina com 4 cores):
  Core 0: |─G1─|─G5─|─G1─|
  Core 1: |─G2─|─G6─|─G2─|              ← paralelismo total
  Core 2: |─G3─|─G7─|─G3─|
  Core 3: |─G4─|─G8─|─G4─|
  → Default desde Go 1.5: runtime.NumCPU()

GOMAXPROCS=8 (em máquina com 4 cores):
  Core 0: |P0|P4|P0|P4|                  ← oversubscription!
  Core 1: |P1|P5|P1|P5|                  ← context switches do kernel
  Core 2: |P2|P6|P2|P6|                  ← entre os M's dos 8 P's
  Core 3: |P3|P7|P3|P7|
  → Geralmente prejudicial para workloads CPU-bound
  → Pode ajudar para workloads com muitas syscalls bloqueantes

GOMAXPROCS em containers

Problema crítico: Em containers com CPU limits, runtime.NumCPU() retorna o número de cores do host, não do container!

// Em um container com cpu.max = "200000 100000" (2 cores):
fmt.Println(runtime.NumCPU())      // Pode imprimir 64! (cores do host)
fmt.Println(runtime.GOMAXPROCS(0)) // GOMAXPROCS = 64 por default!

// Resultado: 64 P's competindo por 2 cores de CPU quota
// → Excessive context switches no kernel
// → Throttling pelo cgroup CPU controller
// → Latência imprevisível

Solução: Use automaxprocs (library da Uber) ou configure manualmente:

import _ "go.uber.org/automaxprocs" // Detecta cgroup limits automaticamente

// Ou manualmente:
func init() {
    if quota := getCGroupCPUQuota(); quota > 0 {
        runtime.GOMAXPROCS(int(math.Ceil(quota)))
    }
}

# Verificar se GOMAXPROCS está correto
$ GODEBUG=schedtrace=1000 ./myservice 2>&1 | head -3
SCHED 0ms: gomaxprocs=2 idleprocs=1 threads=4 idlethreads=1
SCHED 1000ms: gomaxprocs=2 idleprocs=0 threads=5 idlethreads=0
SCHED 2000ms: gomaxprocs=2 idleprocs=1 threads=5 idlethreads=1

# gomaxprocs=2 ← deve corresponder ao CPU limit do container

CPU Affinity e Go

O Go runtime não configura CPU affinity por default — os M's (OS threads) podem migrar entre cores livremente. Para workloads latency-sensitive:

# Pinning do processo Go a cores específicos
$ taskset -c 0-3 ./myservice

# Ou via cgroups (Kubernetes):
# resources.requests.cpu == resources.limits.cpu → cpuset pinning

// Dentro do Go, para pin goroutine a OS thread:
runtime.LockOSThread()  // Esta goroutine fica presa neste M
defer runtime.UnlockOSThread()

// Use cases:
// - CGO com thread-local state
// - OpenGL/GPU contexts
// - Real-time goroutines que precisam de CPU dedicada

Análise de Performance: Blocking Syscalls e Goroutines

A principal armadilha de performance em Go é o excesso de OS threads criados por syscalls bloqueantes — cada goroutine que bloqueia em file I/O, CGO, ou certain syscalls consome um M inteiro.

Diagnóstico: threads demais

# Monitorando OS threads do processo Go
$ cat /proc/<pid>/status | grep Threads
Threads: 847    ← se muito maior que GOMAXPROCS, há goroutines em syscalls

# Trace detalhado do scheduler
$ GODEBUG=schedtrace=1000,scheddetail=1 ./myservice 2>&1 | grep -E "^SCHED|threads"
SCHED 1000ms: gomaxprocs=4 idleprocs=0 threads=847 idlethreads=2
              runqueue=12 [45 38 52 41]
#                         ↑ LRQs dos P's (goroutines esperando)
# threads=847: muitas goroutines bloqueadas em syscalls!
# runqueue=12 + [45+38+52+41] = 188 goroutines ready mas sem P livre

Cenários problemáticos e soluções

Problema 1: File I/O massivo

// ❌ Cada goroutine bloqueia um M em file read
for _, file := range files {
    go func(f string) {
        data, _ := os.ReadFile(f)  // bloqueia M!
        process(data)
    }(file)
}
// Com 10000 files: pode criar 10000 OS threads!

// ✅ Limitar concorrência com semaphore
sem := make(chan struct{}, 64)  // max 64 file I/O simultâneos
for _, file := range files {
    sem <- struct{}{}
    go func(f string) {
        defer func() { <-sem }()
        data, _ := os.ReadFile(f)
        process(data)
    }(file)
}

Problema 2: CGO calls bloqueantes

// CGO: TODA chamada C bloqueia o M
// O runtime NÃO pode preemptar código C

/*
#include <unistd.h>
void slow_c_function() {
    sleep(5);  // bloqueia M por 5 segundos!
}
*/
import "C"

// ✅ Limitar goroutines que chamam CGO
var cgoSem = make(chan struct{}, runtime.GOMAXPROCS(0))

func callCGO() {
    cgoSem <- struct{}{}
    defer func() { <-cgoSem }()
    C.slow_c_function()
}

Problema 3: DNS resolution (usa CGO por default no Linux)

// net.LookupHost usa CGO → bloqueia M
// Sob carga alta, pode criar centenas de threads

// ✅ Solução: usar pure Go resolver
// export GODEBUG=netdns=go
// ou no código:
import _ "net" // com build tag: -tags netgo

Ferramentas de diagnóstico

# 1. Runtime trace (visualização gráfica)
$ curl http://localhost:6060/debug/pprof/trace?seconds=5 > trace.out
$ go tool trace trace.out
# Mostra: goroutine scheduling, syscalls, network I/O, GC

# 2. Goroutine profile
$ curl http://localhost:6060/debug/pprof/goroutine?debug=2
# Lista TODAS goroutines com stack traces
# Procure por: "syscall" no stack = goroutine bloqueando M

# 3. Thread create profile
$ curl http://localhost:6060/debug/pprof/threadcreate?debug=1
# Mostra onde threads foram criadas (indica syscalls bloqueantes)

# 4. perf (kernel-level view)
$ perf stat -e context-switches,cpu-migrations -p <pid> sleep 10
# context-switches alto + muitos threads = problema de blocking syscalls

# 5. Scheduler latency
$ GODEBUG=schedtrace=1000 ./myservice
# Campos importantes:
# - runqueue: goroutines na global queue (> 0 = P's saturados)
# - [n n n n]: goroutines por P na LRQ (desbalanceado = work stealing falhou)
# - idleprocs: P's ociosos (> 0 com runqueue > 0 = bug ou lock contention)

Exemplo Prático: Microserviços Go e Tuning de Concorrência

Cenário: API Gateway em Go com latência degradada sob carga

Ambiente:
- Kubernetes: 4 CPU limit, 4GB RAM
- Go 1.22, ~50k req/s
- Cada request faz: 2-3 chamadas HTTP a backends + 1 Redis lookup
- p50: 8ms, p95: 25ms, p99: 180ms (!) ← degradação no p99

Observações iniciais:
$ cat /proc/<pid>/status
Threads: 312      ← alto para GOMAXPROCS=4 (deveria ser ~10-20)

$ GODEBUG=schedtrace=5000 ./gateway 2>&1 | tail -1
SCHED 5000ms: gomaxprocs=4 idleprocs=0 threads=312 idlethreads=280
              runqueue=0 [2 1 3 0]

Análise:
- threads=312 mas idlethreads=280 → 32 threads ativas em algum momento
- 280 threads idle = foram criadas para syscalls e não foram recicladas
- runqueue baixo = não é falta de P's
- O problema é CRIAÇÃO EXCESSIVA de threads por syscalls bloqueantes

Diagnóstico profundo

# Goroutine dump
$ curl localhost:6060/debug/pprof/goroutine?debug=2 | grep -c "syscall"
28    ← 28 goroutines bloqueadas em syscalls neste instante

# Stack traces das goroutines em syscall:
$ curl localhost:6060/debug/pprof/goroutine?debug=2 | grep -B5 "syscall"
# Revela: net/http.(*Transport).dialConn → net.(*Resolver).lookupHost → CGO!

# perf para confirmar context switches
$ perf stat -p <pid> sleep 10
    45,230  context-switches    ← ~4500/s, alto para 4 cores
     2,890  cpu-migrations      ← threads migrando entre cores

Causa raiz: DNS resolution via CGO criando threads excessivas + HTTP client sem connection pooling adequado.

Solução 1: Pure Go DNS resolver

// main.go — forçar resolver Go puro
import _ "net" // build com: go build -tags netgo

// Ou via variável de ambiente:
// GODEBUG=netdns=go ./gateway

Solução 2: HTTP client com connection pooling otimizado

// ❌ Default: limites conservadores
client := &http.Client{}  // MaxIdleConnsPerHost = 2 (!)

// ✅ Otimizado para alta concorrência
client := &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        200,
        MaxIdleConnsPerHost: 100,   // match com concorrência esperada
        MaxConnsPerHost:     100,   // cap total de conexões por host
        IdleConnTimeout:     90 * time.Second,

        // Tuning TCP-level
        DialContext: (&net.Dialer{
            Timeout:   5 * time.Second,
            KeepAlive: 30 * time.Second,
        }).DialContext,

        // Disable HTTP/2 se backends não suportam multiplexing
        ForceAttemptHTTP2: true,
    },
    Timeout: 10 * time.Second,
}

Solução 3: GOMAXPROCS correto + automaxprocs

import _ "go.uber.org/automaxprocs"

// Resultado: GOMAXPROCS=4 (correto para o container)
// Sem automaxprocs em container com 4 CPU limit em host de 64 cores:
// GOMAXPROCS=64 → 64 P's criando work que 4 cores não conseguem executar

Solução 4: Limitar concorrência de operações bloqueantes

// Semaphore para limitar file/disk I/O concurrent
var diskSem = semaphore.NewWeighted(int64(runtime.GOMAXPROCS(0) * 4))

func readConfig(ctx context.Context, path string) ([]byte, error) {
    if err := diskSem.Acquire(ctx, 1); err != nil {
        return nil, err
    }
    defer diskSem.Release(1)
    return os.ReadFile(path)
}

Resultado após otimização

Antes:                          Depois:
Threads: 312                    Threads: 18
Context switches: 4500/s        Context switches: 800/s
CPU migrations: 290/s           CPU migrations: 45/s
p50: 8ms                        p50: 6ms
p95: 25ms                       p95: 15ms
p99: 180ms                      p99: 35ms  ← 5x melhor!

Monitoramento contínuo em produção

// Expor métricas do runtime para Prometheus
import "github.com/prometheus/client_golang/prometheus"

func init() {
    // Goroutines ativas
    prometheus.MustRegister(prometheus.NewGaugeFunc(
        prometheus.GaugeOpts{Name: "go_goroutines"},
        func() float64 { return float64(runtime.NumGoroutine()) },
    ))

    // OS threads
    prometheus.MustRegister(prometheus.NewGaugeFunc(
        prometheus.GaugeOpts{Name: "go_threads"},
        func() float64 {
            n, _ := runtime.ThreadCreateProfile(nil)
            return float64(n)
        },
    ))
}

# Alertas recomendados (Prometheus):
# - go_threads > GOMAXPROCS * 10 → muitas blocking syscalls
# - go_goroutines > 100000 → possível goroutine leak
# - rate(go_sched_latencies_seconds_sum[5m]) > 0.001 → scheduler saturado

Regras práticas para Go em produção:

GOMAXPROCS = CPU limit do container (use automaxprocs)

go_threads deve ser < GOMAXPROCS * 5 — mais indica blocking syscalls

Use pure Go DNS resolver (GODEBUG=netdns=go ou -tags netgo)

Configure MaxIdleConnsPerHost no HTTP client (default 2 é muito baixo!)

Limite concorrência de file I/O e CGO com semaphores

Monitore com GODEBUG=schedtrace em staging, pprof em produção

Referências Bibliográficas

Livros

Desenvolvimento do Kernel do Linux — Robert Love (David Cram, trad.)
Linux Bible — Christopher Negus
Sistemas Operacionais Modernos — Andrew Tanenbaum
Systems Performance, 2nd Edition — Brendan Gregg (fonte dos valores de benchmark de fork/clone/context switch)

Documentação Oficial

Ferramentas de Observabilidade

perf — profiler e ferramenta de performance do kernel Linux (usado para medir TLB misses, cache misses e context switches)
pidstat — estatísticas de processos e threads (parte do pacote sysstat) (usado para monitorar voluntary/involuntary context switches)
dotnet-counters — ferramenta de monitoramento de runtime .NET (ThreadPool Thread Count, Queue Length, etc.)
dotnet-trace — coleta de traces do runtime .NET
Go pprof — profiler de CPU, memória e goroutines do Go (goroutine dump, threadcreate profile)
go tool trace — visualizador gráfico de traces do Go runtime
GODEBUG=schedtrace — variável de ambiente para debug do scheduler Go
taskset — configuração de CPU affinity para processos
numactl — controle de política de memória e CPU NUMA
numastat — estatísticas de alocação de memória por NUMA node

Bibliotecas e Pacotes

go.uber.org/automaxprocs — detecta automaticamente CPU limits de cgroups e ajusta GOMAXPROCS (Uber)
golang.org/x/sync/semaphore — semáforo com peso para controle de concorrência em Go
github.com/prometheus/client_golang — cliente Prometheus para Go (exposição de métricas de runtime)

Kernel Linux para Desenvolvedores Backend - Processos & Threads Parte III

Alex Volnei Galante — Tue, 09 Jun 2026 14:34:39 +0000

Este artigo é a continuação da Parte II, onde abordamos processos, seu ciclo de vida, syscalls e como os runtimes de Python, Go e .NET os utilizam. Se você ainda não leu, recomendo começar por lá:
Kernel Linux para Desenvolvedores Backend — Processos & Threads Parte II

Sumário

Threads: Fundamentos
- Modelo Clássico de Thread
- Motivação para Threads
- 1. Paralelismo real em múltiplos cores
- 2. Economia de recursos comparado a processos
- 3. Responsividade e overlapping de I/O
- Threads em Espaço de Usuário vs Kernel
- User-Level Threads (ULT) ou Green Threads
- Kernel-Level Threads (KLT)
- Modelos Híbridos (M:N)
- Implementação de Pop-up Threads
- Thread Pools: Conceito e Benefícios
- Comparação: Quando Usar Threads vs Processos
Context Switching: Teoria
- O que é Salvo: Anatomia de um Context Switch

Threads: Fundamentos

Processos são unidades monolíticas de execução. Porém, aplicações modernas — especialmente servidores backend — raramente operam com um único fluxo de execução. Threads permitem que múltiplos fluxos de execução coexistam dentro de um mesmo processo, compartilhando o espaço de endereçamento e recursos, mas mantendo contextos de execução independentes.

Gosto de pensar que threads são linhas de isolamento de processos, porém a nível de kernel uma thread e um processo são a mesma coisa. A grande diferença para você, desenvolvedor backend, é entender a diferença de thread no nível de kernel e thread no nível de usuário, mas isso a gente vai falar mais pra frente.

Documentação Oficial da Kernel - Threads Topology

Modelo Clássico de Thread

Uma thread (ou lightweight process) é a menor unidade de execução escalonável pelo sistema operacional. Enquanto um processo define um espaço de endereçamento e um conjunto de recursos, uma thread define um fluxo de controle dentro desse espaço.

Processo (espaço de endereçamento compartilhado)
┌─────────────────────────────────────────────────────────────┐
│  Code (text segment)     │  Data (global variables)         │
├──────────────────────────┴──────────────────────────────────┤
│  Heap (dynamic allocation)                                  │
├─────────────────────────────────────────────────────────────┤
│  Open files, sockets, signals, credentials, cwd             │
├─────────┬─────────┬─────────┬───────────────────────────────┤
│ Thread 1│ Thread 2│ Thread 3│  ← Cada thread possui:        │
│┌───────┐│┌───────┐│┌───────┐│    - Stack própria            │
││ Stack │││ Stack │││ Stack ││    - Program counter          │
││ PC    │││ PC    │││ PC    ││    - Registradores            │
││ Regs  │││ Regs  │││ Regs  ││    - Estado (running, etc)    │
│└───────┘│└───────┘│└───────┘│    - Thread-local storage     │
└─────────┴─────────┴─────────┴───────────────────────────────┘

O que threads compartilham (pertence ao processo):

Espaço de endereçamento (code, data, heap)
File descriptors abertos
Sinais e handlers de sinais
Working directory e root directory
User ID e Group ID
Memory mappings (mmap)

O que cada thread possui exclusivamente:

Stack (cada thread tem sua própria pilha de execução)
Program counter (aponta para a instrução sendo executada)
Registradores da CPU (salvos/restaurados no context switch)
Estado de escalonamento (running, blocked, ready)
Thread-local storage (TLS) — variáveis privadas por thread
Signal mask (quais sinais estão bloqueados)
errno (em sistemas POSIX)

Essa separação é fundamental: o compartilhamento do espaço de endereçamento permite comunicação eficiente entre threads (basta ler/escrever em memória compartilhada), mas introduz problemas de sincronização e race conditions.

Motivação para Threads

Por que não usar simplesmente múltiplos processos? Threads oferecem três vantagens fundamentais:

1. Paralelismo real em múltiplos cores

Em um servidor com 8 cores, um processo single-threaded utiliza no máximo 12.5% da capacidade de CPU. Threads permitem distribuir trabalho entre todos os cores disponíveis.

Servidor 8 cores — Processando 8 requests simultâneos:

Processo single-threaded:
Core 0: |████████████████████████████████████████████████| (100% — saturado)
Core 1: |                                                | (idle)
Core 2: |                                                | (idle)
...
Core 7: |                                                | (idle)
Throughput: 1x (serializado)

Processo multi-threaded (8 threads):
Core 0: |██████| req 1
Core 1: |██████| req 2
Core 2: |██████| req 3
...
Core 7: |██████| req 8
Throughput: ~8x (paralelo)

2. Economia de recursos comparado a processos

Criar uma thread é significativamente mais barato que criar um processo:

Operação	Custo típico	Motivo
`fork()` (processo)	~100-500μs	Copia page tables, duplica estruturas do kernel
`clone()` (thread)	~10-50μs	Compartilha espaço de endereçamento, aloca apenas stack
Context switch entre processos	~3-5μs	Flush de TLB, troca de page tables
Context switch entre threads (mesmo processo)	~1-2μs	Sem flush de TLB (mesmo espaço de endereçamento)

Fonte: Systems Performance, 2nd Edition — Brendan Gregg; valores de referência medidos com lmbench

A economia é especialmente relevante em servidores que precisam tratar milhares de conexões simultâneas — criar um processo por conexão (modelo Apache pre-fork) é ordens de magnitude mais caro que criar uma thread por conexão.

3. Responsividade e overlapping de I/O

Em aplicações que combinam I/O e computação, threads permitem sobrepor atividades:

Sem threads (serializado):
|── read DB ──|── process ──|── read DB ──|── process ──|── respond ──|
0             50            80           130           160            180ms

Com threads (overlapping):
Thread 1: |── read DB ──|── process ──|── respond ──|
Thread 2:     |── read DB ──|── process ──|
              ↑ I/O concurrent
0             50            80           100ms  ← 44% mais rápido

Implicação para backend: Um servidor web que faz múltiplas queries ao banco de dados para compor uma resposta pode disparar todas as queries em paralelo usando threads, ao invés de executá-las sequencialmente. Frameworks como ASP.NET Core fazem isso nativamente com async/await e o thread pool.

Threads em Espaço de Usuário vs Kernel

A implementação de threads pode ocorrer em diferentes camadas do sistema, cada uma com trade-offs distintos.

User-Level Threads (ULT) ou Green Threads

Threads implementadas inteiramente em espaço de usuário, por uma biblioteca de runtime — sem envolvimento do kernel. O kernel enxerga apenas um único processo.

┌──────────────────────────────────────┐
│         Espaço de Usuário            │
│  ┌──────────────────────────────┐    │
│  │   Thread Library (runtime)   │    │
│  │  ┌─────┐ ┌─────┐ ┌─────┐     │    │
│  │  │ ULT │ │ ULT │ │ ULT │     │    │  ← 3 threads visíveis ao runtime
│  │  │  1  │ │  2  │ │  3  │     │    │
│  │  └─────┘ └─────┘ └─────┘     │    │
│  │        Thread Scheduler      │    │  ← escalonamento em userspace
│  └──────────────────────────────┘    │
├──────────────────────────────────────┤
│              Kernel                  │
│  ┌──────────────────────────────┐    │
│  │ 1 kernel thread (1 processo) │    │  ← kernel vê apenas 1 fluxo
│  └──────────────────────────────┘    │
└──────────────────────────────────────┘

Vantagens:

Context switch ultra-rápido: Troca de thread não envolve trap para o kernel (~100ns vs ~1-2μs)
Portabilidade: Funciona em qualquer OS, independente de suporte a threads no kernel
Customização: O algoritmo de escalonamento pode ser otimizado para a aplicação específica
Escalabilidade: Pode criar milhões de threads (são apenas structs em memória)

Limitações críticas:

Blocking I/O bloqueia todo o processo: Se uma ULT faz uma syscall bloqueante (read, accept), todas as threads do processo param — o kernel não sabe que existem outras threads prontas
Sem paralelismo real: Como o kernel vê apenas um processo, todas as ULTs executam no mesmo core — impossível utilizar múltiplos cores
Page faults bloqueiam tudo: Um page fault em qualquer thread suspende todo o processo

Problema de blocking I/O com ULTs:

ULT 1: |████|── read() ──────────────────|████|
ULT 2: |░░░░|░░░░░░░░░░░░░░░░░░░░░░░░░░░|████|  ← bloqueada esperando ULT 1!
ULT 3: |░░░░|░░░░░░░░░░░░░░░░░░░░░░░░░░░|████|  ← idem

O kernel vê: |████|── BLOCKED ──────────────|████|
             (todo o processo está bloqueado)

Exemplos históricos:

Green threads do Java 1.0, GNU Pth, Solaris LWPs iniciais.
Goroutines do Go são user-level threads, mas o runtime gerencia a multiplexação em OS threads para contornar as limitações de ULTs tradicionais.
Python (antes do GIL) tinha uma implementação de green threads chamada greenlet, mas o GIL tornou isso inviável para paralelismo real.
.NET tinha uma implementação de user-level threads chamada "fibers", mas foi descontinuada em favor do modelo 1:1 com kernel threads.

Kernel-Level Threads (KLT)

Threads gerenciadas diretamente pelo kernel. Cada thread é uma entidade escalonável independente.

┌──────────────────────────────────────┐
│         Espaço de Usuário            │
│  ┌─────┐    ┌─────┐    ┌─────┐       │
│  │ Thr │    │ Thr │    │ Thr │       │  ← 3 threads visíveis ao programa
│  │  1  │    │  2  │    │  3  │       │
│  └──┬──┘    └──┬──┘    └──┬──┘       │
├─────┼──────────┼──────────┼──────────┤
│     ▼          ▼          ▼   Kernel │
│  ┌─────┐    ┌─────┐    ┌─────┐       │
│  │ KLT │    │ KLT │    │ KLT │       │  ← 3 kernel threads (task_structs)
│  │  1  │    │  2  │    │  3  │       │
│  └─────┘    └─────┘    └─────┘       │
│         Kernel Scheduler             │  ← escalonamento pelo kernel
└──────────────────────────────────────┘

Vantagens:

Paralelismo real: Threads podem executar simultaneamente em diferentes cores
I/O não bloqueia outras threads: Se thread 1 bloqueia em I/O, threads 2 e 3 continuam executando
Escalonamento justo: O kernel aplica as mesmas políticas (CFS, etc.) a todas as threads

Desvantagens:

Overhead de criação: Cada thread requer alocação de task_struct, stack de kernel (~8-16KB), e entrada na tabela de processos
Context switch mais caro: Requer transição user→kernel→user
Escalabilidade limitada: Criar milhares de threads é viável, mas milhões não — cada uma consome memória de kernel e sobrecarrega o escalonador
Sincronização via syscalls: Operações como mutex lock/unlock requerem traps para o kernel

Modelo 1:1 — No Linux moderno (NPTL - Native POSIX Thread Library), cada thread POSIX mapeia diretamente para uma kernel thread. Este é o modelo usado por:

Python (cada thread Python = 1 kernel thread)
.NET (cada thread gerenciada = 1 kernel thread)
Java (desde Java 1.3+)
Go (cada goroutine é multiplexada em OS threads, mas o modelo é efetivamente 1:1 para threads do kernel)

# Verificando threads de um processo
$ ls /proc/1350/task/
1350  1351  1352  1353    ← 4 threads (4 task_structs no kernel)

$ cat /proc/1350/status | grep Threads
Threads: 4

Modelos Híbridos (M:N)

O modelo M:N combina M user-level threads mapeadas em N kernel threads (onde M >> N). Busca obter o melhor dos dois mundos: escalabilidade de ULTs com paralelismo de KLTs.

┌───────────────────────────────────────────────────┐
│              Espaço de Usuário                    │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐  │
│  │UT 1 │ │UT 2 │ │UT 3 │ │UT 4 │ │UT 5 │ │UT 6 │  │ ← M user threads
│  └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘  │
│     │    ╲  │   ╱   │       │   ╲   │   ╱   │     │
│     ▼     ╲ ▼  ╱    ▼       ▼    ╲  ▼  ╱    ▼     │ ← multiplexação
│  ┌─────────────┐  ┌───────┐  ┌─────────────┐      │
│  │ User Sched  │  │ U.S.  │  │ User Sched  │      │
├──┴──────┬──────┴──┴───┬───┴──┴──────┬──────┴──────┤
│         ▼             ▼             ▼      Kernel │
│      ┌─────┐       ┌─────┐       ┌─────┐          │
│      │KLT 1│       │KLT 2│       │KLT 3│          │ ← N kernel threads
│      └─────┘       └─────┘       └─────┘          │
│              Kernel Scheduler                     │
└───────────────────────────────────────────────────┘

M = 6 user threads, N = 3 kernel threads → modelo 6:3 (ou 2:1)

Vantagens do M:N:

Pode criar milhões de user threads sem sobrecarregar o kernel
Paralelismo real (N kernel threads em N cores)
Context switch rápido entre user threads no mesmo kernel thread
Blocking syscalls podem ser mascaradas (a runtime move outras user threads para KLTs livres)

Desafios:

Complexidade de implementação significativa
Coordenação entre user scheduler e kernel scheduler
Debugging mais difícil (stack traces podem ser confusos)
Sincronização entre user threads e kernel primitives

O exemplo mais bem-sucedido de M:N na prática: o Go runtime.

Go runtime (modelo M:N):

G (Goroutines):  G1  G2  G3  G4  G5  G6 ... G100000  ← milhões possíveis
                  │   │   │   │   │   │
                  └───┴───┼───┴───┴───┘
                          │
M (OS Threads):     M1    M2    M3    M4         ← GOMAXPROCS kernel threads
                    │     │     │     │
P (Processors):     P1    P2    P3    P4         ← logical processors

- G: goroutine (~2KB stack inicial, cresce dinamicamente)
- M: kernel thread (task_struct no Linux)
- P: contexto de processamento (run queue local)

Conexão com linguagens backend:

Python: Modelo 1:1 (cada thread = kernel thread), mas o GIL impede paralelismo real para código Python puro

.NET: Modelo 1:1 para threads, mas Task/async-await implementa um scheduler cooperativo em userspace sobre o thread pool

Go: Modelo M:N verdadeiro — goroutines são user-level threads multiplexadas em OS threads pelo Go scheduler

Implementação de Pop-up Threads

Pop-up threads são um padrão onde threads são criadas dinamicamente em resposta a eventos (tipicamente mensagens de rede chegando). Ao invés de manter um pool de threads bloqueadas em accept()/recv(), uma nova thread é "disparada" (pop-up) para tratar cada mensagem.

Modelo tradicional (thread pool blocking):
Thread 1: |── accept() ──────|── handle ──|── accept() ──────|
Thread 2: |── accept() ──────────────────────|── handle ──|
Thread 3: |── accept() ──────────────────────────────────────|  ← idle, desperdiçando stack

Modelo pop-up:
                    msg arrives
                         │
                         ▼
Dispatcher: |── wait ──|── spawn ──|── wait ──|── spawn ──|
                              │                      │
Pop-up T1:                    |── handle ──|         │
Pop-up T2:                                           |── handle ──|
                              ↑                      ↑
                     thread criada sob demanda (sem estado prévio)

Vantagens:

Thread começa "fresca" — sem estado anterior para salvar/restaurar
Criação é mais rápida que acordar uma thread bloqueada (em implementações otimizadas)
Sem overhead de threads ociosas consumindo stack

Desvantagens:

Custo de criação pode ser alto se threads são kernel-level
Sem limite inerente — pode criar threads demais sob carga alta (thundering herd)

Na prática, o conceito de pop-up threads inspirou modelos como:

Goroutines em Go: extremamente baratas de criar (~2KB), usadas como pop-up threads para cada request
Task.Run em .NET: cria uma task (executada por uma thread do pool) para cada operação
Event-driven + thread pool: Node.js, asyncio — o event loop despacha trabalho CPU-bound para threads do pool

Thread Pools: Conceito e Benefícios

Um thread pool é um conjunto pré-alocado de threads que aguardam trabalho em uma fila. Ao invés de criar e destruir threads para cada tarefa, as threads são reutilizadas.

Thread Pool:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   Work Queue:  [Task A] → [Task B] → [Task C] → ...         │
│                    │                                        │
│                    ▼                                        │
│   ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐            │
│   │Thread 1│  │Thread 2│  │Thread 3│  │Thread 4│            │
│   │ (busy) │  │ (busy) │  │(waitin)│  │(waitin)│            │
│   └────────┘  └────────┘  └────────┘  └────────┘            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Benefícios:

Amortização do custo de criação: Threads são criadas uma vez e reutilizadas milhares de vezes
Controle de recursos: Limita o número máximo de threads, prevenindo esgotamento de memória
Redução de latência: Thread já existe quando o trabalho chega — não há atraso de criação
Backpressure natural: Quando o pool está saturado, novas tarefas aguardam na fila, fornecendo um mecanismo natural de controle de carga

Dimensionamento do thread pool — uma das decisões mais impactantes para performance de backend:

Para workloads I/O-bound:
  Threads ≈ N_cores × (1 + Wait_time / Service_time)

  Exemplo: 8 cores, ratio wait/service = 9 (90% I/O)
  Threads ≈ 8 × (1 + 9) = 80 threads

Para workloads CPU-bound:
  Threads ≈ N_cores (ou N_cores + 1)

  Exemplo: 8 cores, computação pura
  Threads ≈ 8

Exemplos em linguagens backend:

Python (Gunicorn): Workers (processos) com threads — workers = 2*cores + 1, threads = 2-4 por worker

.NET (ThreadPool): Auto-tuning com hill climbing algorithm — começa com Environment.ProcessorCount threads e ajusta dinamicamente

Go: Não usa thread pool explícito — o runtime gerencia OS threads dinamicamente (geralmente GOMAXPROCS = número de cores)

# Monitorando thread pool em produção

# .NET: ThreadPool stats
$ dotnet-counters monitor --process-id 950 System.Runtime
    ThreadPool Thread Count:    24
    ThreadPool Queue Length:     0
    ThreadPool Completed Items: 1,234,567

# Python: verificando threads de workers Gunicorn
$ ps -eLf | grep gunicorn | wc -l
48    # 16 workers × 3 threads cada

# Go: goroutines vs OS threads
# (via pprof ou GODEBUG=schedtrace=1000)
SCHED 1000ms: gomaxprocs=8 idleprocs=2 threads=10 idlethreads=3
              runqueue=0 [2 0 1 0 0 3 0 0]

Comparação: Quando Usar Threads vs Processos

A escolha entre threads e processos é uma decisão arquitetural fundamental para aplicações backend:

Critério	Threads	Processos
Isolamento	Fraco — crash em uma thread pode corromper todo o processo	Forte — crash isolado, outros processos continuam
Comunicação	Rápida — memória compartilhada direta	Lenta — IPC (pipes, sockets, shared memory explícita)
Overhead de criação	Baixo (~10-50μs)	Alto (~100-500μs)
Context switch	Rápido (mesmo address space)	Lento (TLB flush, troca de page tables)
Escalabilidade	Limitada pela memória de stack (milhares)	Limitada pela tabela de processos (milhares)
Debugging	Difícil (race conditions, deadlocks)	Mais simples (estados isolados)
Security	Mesmas permissões, uma vulnerabilidade compromete tudo	Isolamento de permissões possível

Quando usar PROCESSOS:
├── Isolamento é crítico (ex: processando dados de múltiplos tenants)
├── O código pode crashar (ex: extensões C/C++ instáveis)
├── Precisa de security boundaries (ex: sandbox por request)
└── Linguagem tem GIL (Python) e precisa de paralelismo CPU

Quando usar THREADS:
├── Comunicação frequente entre unidades de trabalho
├── Baixa latência de criação é importante
├── Workload é I/O-bound (threads bloqueiam em I/O independentemente)
└── Memória compartilhada simplifica a arquitetura

Decisões práticas por linguagem:

Python: Use processos (multiprocessing/Gunicorn workers) para CPU-bound; threads para I/O-bound (apesar do GIL, threads liberam o GIL durante I/O); asyncio para alta concorrência I/O

.NET: Use threads/Tasks para tudo (sem GIL); processos apenas para isolamento extremo

Go: Use goroutines para tudo — o runtime gerencia a complexidade; processos separados apenas para isolamento de serviços (microserviços)

Context Switching: Teoria

O context switch (troca de contexto) é o mecanismo pelo qual o kernel salva o estado de um processo/thread em execução e restaura o estado de outro, efetivamente transferindo a CPU de uma unidade de execução para outra. Embora invisível para a aplicação, o context switch é uma operação que ocorre milhares de vezes por segundo em um servidor backend — e seu custo acumulado pode ser significativo.

O que é Salvo: Anatomia de um Context Switch

Quando o kernel decide trocar o processo/thread em execução, ele precisa preservar todo o estado necessário para que o processo interrompido possa ser retomado exatamente de onde parou, como se nada tivesse acontecido.

Estado salvo por hardware (automático na troca de privilégio)

Na arquitetura x86-64, quando ocorre uma interrupção ou trap que causa transição para kernel mode, o processador automaticamente salva na kernel stack:

Stack do kernel após interrupção (x86-64):
┌─────────────────────┐  ← topo da kernel stack
│ SS (user stack seg) │
│ RSP (user stack ptr)│
│ RFLAGS              │  ← flags de status (carry, zero, overflow, interrupt enable)
│ CS (code segment)   │
│ RIP (program count) │  ← instrução onde o processo foi interrompido
└─────────────────────┘

Estado salvo pelo kernel (software)

O kernel salva explicitamente o restante do contexto na task_struct (ou estrutura associada como thread_struct):

Contexto salvo pelo kernel:
┌─────────────────────────────────────────────────────────┐
│ Registradores de Propósito Geral                        │
│   RAX, RBX, RCX, RDX, RSI, RDI, RBP                     │
│   R8, R9, R10, R11, R12, R13, R14, R15                  │
├─────────────────────────────────────────────────────────┤
│ Program Counter (RIP) e Stack Pointer (RSP)             │
├─────────────────────────────────────────────────────────┤
│ Registradores de Segmento (FS, GS — usados para TLS)    │
├─────────────────────────────────────────────────────────┤
│ Estado da FPU/SSE/AVX                                   │
│   Registradores XMM0-XMM15 (128 bits cada)              │
│   Registradores YMM0-YMM15 (256 bits — AVX)             │
│   Registradores ZMM0-ZMM31 (512 bits — AVX-512)         │
│   MXCSR (controle SSE)                                  │
│   x87 FPU state (legacy)                                │
├─────────────────────────────────────────────────────────┤
│ Estado de Debug (DR0-DR7) — se em uso                   │
├─────────────────────────────────────────────────────────┤
│ Informações de Escalonamento                            │
│   vruntime, prioridade efetiva, timeslice restante      │
├─────────────────────────────────────────────────────────┤
│ Kernel stack pointer                                    │
└─────────────────────────────────────────────────────────┘

O estado FPU/SIMD é particularmente volumoso — com AVX-512, pode ser mais de 2KB por contexto. O Linux usa lazy FPU saving (ou, em kernels modernos, eager FPU saving com XSAVE/XRSTOR) para otimizar esse custo.

O que NÃO é salvo (compartilhado entre threads do mesmo processo)

Espaço de endereçamento (page tables) — por isso context switch entre threads é mais barato
File descriptors
Sinais e handlers
Credenciais (UID/GID)
Working directory

Continua na parte IV

Conteudo parcialmente gerado com auxilio de IA generativa (eu organizei o conteudo e ela me ajudou com lero lero, novos tempos kkkk)

Referências Bibliográficas

Livros

Desenvolvimento do Kernel do Linux — Robert Love (David Cram, trad.)
Linux Bible — Christopher Negus
Sistemas Operacionais Modernos — Andrew Tanenbaum
Systems Performance, 2nd Edition — Brendan Gregg (fonte dos valores de benchmark de fork/clone/context switch)

Documentação Oficial

Ferramentas

lmbench — benchmark de latências de OS (utilizado para medir custos de fork, clone e context switch)

Kernel Linux para Desenvolvedores Backend - Processos & Threads Parte II

Alex Volnei Galante — Mon, 08 Jun 2026 18:39:01 +0000

Este artigo é a continuação da Parte I, onde abordamos processos, seu ciclo de vida, syscalls e como os runtimes de Python, Go e .NET os utilizam. Se você ainda não leu, recomendo começar por lá:
Kernel Linux para Desenvolvedores Backend — Processos & Threads Parte I

Sumário da Parte II

Escalonamento de Processos
- Categorias de Algoritmos de Escalonamento
- Algoritmos para Batch Systems
  - First-Come, First-Served (FCFS)
  - Shortest Job First (SJF)
- Algoritmos para Interactive Systems
  - Round-Robin (RR)
  - Priority Scheduling
- Algoritmos para Real-Time Systems
- Escalonamento Preemptivo vs Não-Preemptivo
- Problema da Inversão de Prioridade
- Starvation e Aging
- Como o Linux Implementa Escalonamento: Visão Geral
- Prioridades e Nice Values
- Métricas de Escalonamento na Prática
Referências Bibliográficas

Escalonamento de Processos

A peça fundamental que realiza toda a máquina de estados com processos no kernel é o escalonador. Vamos começar com uma base teórica sobre os algoritmos de escalonamento, suas categorias e como o Linux implementa isso na prática.

Categorias de Algoritmos de Escalonamento

Os algoritmos de escalonamento são projetados para diferentes tipos de sistemas, cada um com prioridades distintas.

Algoritmos para Batch Systems

Sistemas batch priorizam throughput e turnaround time. Não há usuário interativo esperando resposta.

First-Come, First-Served (FCFS)

Detalhe completo no link https://www.geeksforgeeks.org/dsa/first-come-first-serve-cpu-scheduling-non-preemptive/ — é o algoritmo mais simples, mas pode levar a tempos de espera muito altos para processos curtos (efeito comboio).

Executa os processos na ordem de chegada. O processo que chega primeiro é executado até terminar, depois o próximo, e assim por diante.

  Fila de chegada: P1(24ms) → P2(3ms) → P3(3ms)

  Execução FCFS:
  |────────── P1 (24ms) ──────────|─ P2 (3ms) ─|─ P3 (3ms) ─|
  0                               24            27            30

  Waiting time médio: (0 + 24 + 27) / 3 = 17ms

  Se a ordem fosse P2, P3, P1:
  |─ P2 ─|─ P3 ─|────────── P1 (24ms) ──────────|
  0       3       6                               30

  Waiting time médio: (0 + 3 + 6) / 3 = 3ms  ← 5.7x melhor!

O efeito comboio (convoy effect) é o problema clássico do FCFS: um processo CPU-bound longo bloqueia todos os demais. Isso é análogo a ter uma query SQL pesada bloqueando o único worker disponível.

Shortest Job First (SJF)

Detalhe completo no link https://translate.google.com/translate?u=https://www.geeksforgeeks.org/operating-systems/shortest-job-first-or-sjf-cpu-scheduling/&hl=pt&sl=en&tl=pt&client=srp —

Executa primeiro o processo com menor tempo estimado de CPU. É provadamente ótimo para minimizar o waiting time médio — mas requer conhecimento prévio do tempo de execução, o que raramente é possível.

  Processos: P1(6ms), P2(8ms), P3(7ms), P4(3ms)

  FCFS:  |─ P1(6) ─|── P2(8) ──|─ P3(7) ─|─P4(3)─|
        Waiting médio: (0+6+14+21)/4 = 10.25ms

  SJF:   |P4(3)|─ P1(6) ─|─ P3(7) ─|── P2(8) ──|
        Waiting médio: (0+3+9+16)/4 = 7ms  ← ótimo

Na prática, SJF inspira heurísticas usadas em load balancers e connection schedulers: redirecionar requisições para o worker que deve terminar mais rápido (least-connections, por exemplo).

Algoritmos para Interactive Systems

Sistemas interativos — onde se encaixam a maioria das aplicações backend — priorizam response time e fairness.

Round-Robin (RR)

Detalhe completo no link https://www.geeksforgeeks.org/operating-systems/round-robin-scheduling-in-operating-system/

Cada processo recebe um quantum (timeslice) fixo de CPU. Ao esgotar o quantum, é preemptado e colocado no final da fila.

Quantum = 4ms
Processos: P1(24ms), P2(3ms), P3(3ms)

|─P1(4)─|P2(3)|P3(3)|─P1(4)─|─P1(4)─|─P1(4)─|─P1(4)─|P1(4)|
0        4     7    10      14      18      22      26    30

P2 termina em t=7  (vs t=27 no FCFS)
P3 termina em t=10 (vs t=30 no FCFS)

O Round-Robin é a base conceitual sobre a qual o CFS do Linux foi construído — embora o CFS use uma abordagem muito mais sofisticada baseada em virtual runtime.

A escolha do quantum é crítica:

Muito pequeno (< 1ms): overhead de context switch domina — a CPU gasta mais tempo trocando de processo do que executando
Muito grande (> 100ms): degenera para FCFS — processos interativos sofrem
Regra empírica: 80% dos CPU bursts devem ser menores que o quantum

Priority Scheduling

Detalhe completo no link https://www.geeksforgeeks.org/operating-systems/priority-scheduling-in-operating-system/

Cada processo recebe uma prioridade. O processo de maior prioridade executa primeiro.

Prioridades (menor número = maior prioridade):

Prioridade 1: ├── Kernel threads (interrupts, softirqs)
Prioridade 2: ├── Processos real-time (SCHED_FIFO, SCHED_RR)
              │   └── Exemplo: audio processing, controle industrial
Prioridade 3: ├── Processos normais com nice negativo
              │   └── Exemplo: nginx worker com nice -5
Prioridade 4: ├── Processos normais (nice 0)
              │   └── Exemplo: sua API Python/Go/.NET
Prioridade 5: └── Processos de baixa prioridade (nice positivo)
                  └── Exemplo: backup, log rotation

O problema fundamental do priority scheduling é o starvation: processos de baixa prioridade podem nunca executar se processos de alta prioridade estão sempre prontos.

Algoritmos para Real-Time Systems

Sistemas real-time precisam de garantias temporais — deadlines que devem ser cumpridos.

Rate Monotonic Scheduling (RMS)

Atribui prioridade fixa inversamente proporcional ao período da tarefa. Tarefas com períodos menores (mais frequentes) recebem prioridade mais alta.

Earliest Deadline First (EDF)

Prioridade dinâmica: o processo com deadline mais próximo executa primeiro. Teoricamente ótimo — pode atingir 100% de utilização de CPU.

Conexão com o kernel: O Linux suporta escalonamento real-time via SCHED_FIFO, SCHED_RR e, a partir do kernel 3.14, SCHED_DEADLINE (baseado em EDF). Embora a maioria das aplicações backend não precise de real-time, entender essas classes é importante para diagnosticar problemas quando um processo real-time inadvertidamente monopoliza CPU.

Escalonamento Preemptivo vs Não-Preemptivo

A distinção entre escalonamento preemptivo e não-preemptivo é fundamental para entender o comportamento do Linux:

Não-preemptivo (cooperativo): O processo mantém a CPU até voluntariamente liberá-la (terminar, bloquear em I/O, ou ceder via yield()). Simples, mas um processo mal-comportado pode monopolizar a CPU.

Preemptivo: O kernel pode forçar a remoção de um processo da CPU a qualquer momento (tipicamente quando seu timeslice expira ou um processo de maior prioridade fica pronto). Mais complexo, mas garante responsividade.

Não-preemptivo:
P1 (CPU-bound, buggy): |████████████████████████████████████████|
P2 (sua API):          |░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░|  ← nunca executa!

Preemptivo (quantum = 10ms):
P1: |████|    |████|    |████|    |████|    |████|
P2:      |████|    |████|    |████|    |████|
          ↑ kernel preempta P1

O Linux é totalmente preemptivo no userspace — o kernel pode preemptar qualquer processo em modo usuário a qualquer momento. O kernel em si tem diferentes níveis de preempção configuráveis:

Configuração	Comportamento	Uso típico
`PREEMPT_NONE`	Kernel não-preemptivo	Servidores de throughput máximo
`PREEMPT_VOLUNTARY`	Preempção em pontos explícitos	Default na maioria das distros server
`PREEMPT_FULL`	Kernel totalmente preemptivo	Desktop, baixa latência
`PREEMPT_RT`	Real-time, preempção determinística	Sistemas embarcados, áudio profissional

Implicação prática: Distros server como Ubuntu Server e RHEL usam PREEMPT_VOLUNTARY por default. Se sua aplicação precisa de latência ultra-baixa (ex: trading), pode ser benéfico usar um kernel com PREEMPT_FULL ou PREEMPT_RT.

Implicação prática: Imagens docker que utilizam o kernel do host herdam a configuração de preempção do host. Portanto, mesmo dentro de um container, o comportamento de escalonamento é ditado pelo kernel do host.

Problema da Inversão de Prioridade

A inversão de prioridade ocorre quando um processo de alta prioridade é indiretamente bloqueado por um de baixa prioridade, violando a política de escalonamento.

Cenário clássico (Mars Pathfinder, 1997):

Prioridade Alta (H):   Task meteorológica (deadline crítico)
Prioridade Média (M):  Task de comunicação (longa)
Prioridade Baixa (L):  Task de coleta de dados

Sequência do problema:
1. L adquire mutex M₁
2. L é preemptado por H
3. H tenta adquirir M₁ → bloqueado (L detém M₁)
4. M fica pronto e executa (maior prioridade que L)
5. M executa por tempo arbitrário
6. H continua bloqueado — inversão de prioridade!

Timeline:
L:  |██|      |░░░░░░░░░░░░░░░░|██|──unlock──|
M:  |  |      |████████████████|  |           |
H:  |  |██|→blocked            |  |           |██████|
         ↑                                     ↑
    tenta lock                            finalmente executa

Soluções:

Priority Inheritance: Quando H bloqueia em um lock detido por L, L temporariamente "herda" a prioridade de H, impedindo que M execute no meio. O kernel Linux implementa isso para rt_mutex.
Priority Ceiling: O mutex recebe a prioridade do processo de maior prioridade que pode usá-lo. Qualquer processo que adquire o mutex tem sua prioridade elevada ao ceiling.

Implicação prática: Em Go, a inversão de prioridade pode ocorrer entre goroutines quando uma goroutine de alta prioridade (tratando request HTTP) bloqueia em um sync.Mutex detido por uma goroutine de baixa prioridade (fazendo log assíncrono), enquanto goroutines de prioridade média consomem os threads do runtime. O scheduler do Go não implementa priority inheritance — é responsabilidade do desenvolvedor minimizar a contenção de locks.

Starvation e Aging

Starvation ocorre quando um processo nunca recebe CPU porque processos de maior prioridade estão sempre prontos. Em sistemas com priority scheduling puro, processos de baixa prioridade podem ser indefinidamente postergados.

Starvation:
Tempo →  0    10    20    30    40    50    60    70    80
Prio 1:  |████|████|████|████|████|████|████|████|████|
Prio 2:  |░░░░|░░░░|░░░░|░░░░|░░░░|░░░░|░░░░|░░░░|░░░░|  ← nunca executa!

Aging é a solução clássica: a prioridade de um processo aumenta gradualmente quanto mais tempo ele espera na ready queue. Eventualmente, mesmo o processo de menor prioridade terá prioridade suficiente para executar.

Aging:
Tempo →  0    10    20    30    40    50    60
Prio P2: 10   11    12    13    14    15    16  ← agora compete com Prio 1!
                                          |████| P2 finalmente executa

O CFS do Linux implementa uma forma sofisticada de aging através do virtual runtime: processos que receberam menos CPU têm vruntime menor e são naturalmente favorecidos pelo escalonador. Isso torna starvation virtualmente impossível no CFS.

Como o Linux Implementa Escalonamento: Visão Geral

O escalonador do Linux organiza os algoritmos em scheduling classes, cada uma implementando uma política diferente:

Hierarquia de Scheduling Classes (maior → menor prioridade):

    ┌─────────────────────────────────────────────┐
    │  stop_sched_class                           │ ← Migration threads (interno)
    ├─────────────────────────────────────────────┤
    │  dl_sched_class (SCHED_DEADLINE)            │ ← EDF: deadline-based
    ├─────────────────────────────────────────────┤
    │  rt_sched_class (SCHED_FIFO,SCHED_RR)       │ ← Real-time: prioridade fixa
    ├─────────────────────────────────────────────┤
    │  fair_sched_class (SCHED_NORMAL,SCHED_BATCH)│ ← CFS: a maioria dos processos
    ├─────────────────────────────────────────────┤
    │  idle_sched_class (SCHED_IDLE)              │ ← Executa apenas quando nada mais
    └─────────────────────────────────────────────┘

O kernel percorre as classes de cima para baixo.
Se uma classe de maior prioridade tem um processo pronto, ele executa.

Para a vasta maioria das aplicações backend, os processos rodam na classe fair_sched_class com política SCHED_NORMAL. É aqui que o CFS (Completely Fair Scheduler) — e seu sucessor EEVDF no kernel 6.6+ — opera.

Prioridades e Nice Values

O Linux mapeia o conceito de prioridade em dois espaços numéricos:

Nice values (userspace):     -20 ────────── 0 ────────── +19
                              ↑ maior prio   normal      ↑ menor prio

Static priority (kernel):     100 ─────────120─────────── 139
                              ↑ nice -20   nice 0        ↑ nice +19

Real-time priorities:         0 ──────────────────────── 99
                              ↑ menor prio rt            ↑ maior prio rt

# Executando um processo com prioridade alterada
$ nice -n -5 python3 app.py          # maior prioridade (precisa de root para nice < 0)
$ nice -n 10 python3 batch_job.py    # menor prioridade

# Alterando prioridade de processo em execução
$ renice -n -5 -p 1350               # aumenta prioridade do PID 1350

# Verificando nice value
$ ps -eo pid,ni,comm | grep python
1350  -5 python3
1400  10 python3

Dica prática: Em um servidor que roda tanto APIs quanto batch jobs, use nice para dar menor prioridade aos batch jobs. Isso garante que suas APIs mantêm boa responsividade mesmo durante processamento pesado em background.

Métricas de Escalonamento na Prática

Para avaliar como o escalonamento afeta sua aplicação, monitore estas métricas:

# Context switches do sistema (total)
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 245612  45632 1234567    0    0     5    12  256 4521 15  3 80  2  0
                                                           ↑    ↑
                                                     interrupts  context switches

# Context switches por processo
$ cat /proc/<pid>/status | grep ctxt
voluntary_ctxt_switches:    15230
nonvoluntary_ctxt_switches: 892

# Run queue length (processos aguardando CPU)
$ cat /proc/loadavg
2.15 1.80 1.45 3/412 28503
↑    ↑    ↑    ↑
1m   5m   15m  running/total

# Latência de escalonamento com perf
$ perf sched latency
-------------------------------------------------
  Task                  |   Runtime ms  | Switches | Avg delay ms |
-------------------------------------------------
  python3:1350          |    1052.340   |    15230 |    0.045     |
  dotnet:950            |     876.230   |     8920 |    0.032     |
  nginx:601             |     234.120   |    42310 |    0.012     |

A coluna Avg delay ms no perf sched latency mostra quanto tempo, em média, o processo esperou na ready queue antes de ser escalonado. Valores altos indicam contenção de CPU.

# Visualizando scheduling events em tempo real
$ perf sched record -- sleep 10    # grava 10 segundos
$ perf sched map                   # mapa visual de scheduling

# Exemplo de saída:
#           *A0          . .  .  .  .  .  .    846.275762 secs A0 => python3:1350
#            A0          *B0 .  .  .  .  .     846.275800 secs B0 => nginx:601
#            A0           B0 *C0 .  .  .  .    846.275845 secs C0 => postgres:1500
#           *A0           B0  C0 .  .  .  .    846.275900 secs
#            A0          *B0  C0 .  .  .  .    846.275950 secs

Continua na parte III

Conteudo parcialmente gerado com auxilio de IA generativa (eu organizei o conteudo e ela me ajudou com lero lero, novos tempos kkkk)

Referencias Bibliográficas

Kernel Linux para Desenvolvedores Backend - Processos & Threads Parte I

Alex Volnei Galante — Mon, 08 Jun 2026 18:09:13 +0000

Sumário da Parte I

Introdução ao Kernel Linux
Estrutura do Kernel
Gerenciamento de Processos
Sua aplicação e o Kernel
Referências Bibliográficas

Introdução ao Kernel Linux

A história começa em meados de 1991 quando um nerd que vivia em um país congelado chamado Linus Torvalds decidiu criar um sistema operacional baseado no Unix, mas que fosse gratuito e de código aberto. Ele começou a escrever o código do kernel do Linux em seu computador pessoal, e em pouco tempo, o projeto ganhou a atenção de outros desenvolvedores ao redor do mundo.

A história completa do Linux e sua união com o GNU pode ser encontrada no livro "Just for Fun: The Story of an Accidental Revolutionary" de Linus Torvalds, é uma leitura muito interessante para quem quer entender a história do Linux e como ele se tornou o que é hoje.

Estrutura do Kernel

O kernel possui uma estrutura super complexa, mas podemos dividi-lo em 3 blocos fundamentais:

User Space: onde os aplicativos e processos rodam, é a parte com a qual os desenvolvedores backend têm mais contato.
Kernel Space: onde o kernel do Linux roda, é a parte que gerencia os recursos de hardware e fornece uma interface para os aplicativos.
System Calls: é a interface entre o user space e o kernel space, é onde os aplicativos fazem chamadas para o kernel para acessar recursos de hardware ou realizar operações privilegiadas.

Subsistemas do Kernel

O kernel do Linux é composto por vários subsistemas, cada um responsável por uma parte específica do sistema operacional. Alguns dos subsistemas mais importantes incluem:

Gerenciamento de Processos: responsável por criar, gerenciar e finalizar processos no sistema.
Gerenciamento de Memória: responsável por alocar e liberar memória para os processos.
Gerenciamento de Arquivos: responsável por gerenciar o sistema de arquivos e fornecer uma interface para os aplicativos acessarem arquivos.
Gerenciamento de Dispositivos: responsável por gerenciar os dispositivos de hardware e fornecer uma interface para os aplicativos acessarem esses dispositivos.
Gerenciamento de Rede: responsável por gerenciar as conexões de rede e fornecer uma interface para os aplicativos se comunicarem pela rede.

Nessa primeira parte, nosso objetivo é desvendar o subsistema de gerenciamento de processos, entender como ele funciona e como ele pode impactar o desenvolvimento backend.
Vamos primeiramente entender o que são processos e threads, e como o kernel do Linux gerencia esses recursos.

Processos

Um processo é a abstração mais fundamental que um sistema operacional oferece para a execução de programas. Em termos simples, um processo é um programa em execução — mas essa definição esconde uma complexidade considerável.

Quando você executa uma aplicação backend — seja um servidor Flask, uma API ASP.NET Core ou um microserviço em Go — o kernel Linux cria um processo que encapsula tudo o que é necessário para aquela execução:

Espaço de endereçamento: uma região de memória virtual exclusiva contendo o código (text), dados globais (data/BSS), heap e stack
Registradores da CPU: o program counter (PC/RIP), o stack pointer (SP/RSP), registradores de propósito geral e registradores de status
Recursos do sistema: file descriptors abertos, sinais pendentes, informações de credenciais, working directory, mapeamentos de memória

Cada processo opera sob a ilusão de que possui a máquina inteira para si (assim como um S.O virtualizado acredita que controla o hardware completo rsrsrsr). Essa ilusão é construída pelo kernel através de duas abstrações principais: virtualização de CPU (escalonamento) e virtualização de memória (memória virtual).

Multiprogramação e Pseudoparalelismo

Em um sistema com uma única CPU, apenas um processo pode executar instruções em um dado instante. No entanto, o kernel alterna entre processos tão rapidamente que, para um observador humano, parece que todos executam simultaneamente. Esse fenômeno é chamado de pseudoparalelismo.

A multiprogramação é a técnica que permite manter múltiplos processos em memória ao mesmo tempo, alternando a CPU entre eles. O objetivo é maximizar a utilização da CPU: quando um processo bloqueia aguardando I/O (uma query ao banco de dados, uma leitura de disco, uma resposta de rede), outro processo pode utilizar a CPU.

Tempo →
CPU:  |--P1--|--P2--|--P1--|--P3--|--P2--|--P1--|

P1:   ██████░░░░░░██████░░░░░░░░░░░░░░░░██████
P2:   ░░░░░░██████░░░░░░░░░░░░░░░░██████░░░░░░
P3:   ░░░░░░░░░░░░░░░░░░██████░░░░░░░░░░░░░░░░

██ = executando    ░░ = aguardando/pronto

Para aplicações backend, esse modelo tem implicações diretas:

Servidores web multi-processo (Gunicorn com workers pre-fork, por exemplo) dependem do kernel para distribuir tempo de CPU entre os workers
Microserviços em containers competem por CPU com outros containers no mesmo host
A latência de resposta da sua API é diretamente afetada pela capacidade do kernel de escalonar seu processo de forma eficiente.

Hierarquia de Processos

No Linux, processos formam uma árvore hierárquica. Todo processo (exceto o init/systemd, PID 1) possui um processo pai que o criou. Essa relação é estabelecida pela system call fork() (ou, mais modernamente, clone()).

systemd (PID 1)
├── sshd (PID 512)
│   └── bash (PID 1200)
│       └── python app.py (PID 1350)
│           ├── worker-1 (PID 1351)
│           ├── worker-2 (PID 1352)
│           └── worker-3 (PID 1353)
├── dockerd (PID 800)
│   └── containerd-shim (PID 900)
│       └── dotnet MyApi.dll (PID 950)
└── nginx (PID 600)
    ├── nginx worker (PID 601)
    └── nginx worker (PID 602)

Essa hierarquia não é meramente organizacional — ela tem consequências práticas:

Sinais: quando um processo pai termina, sinais são enviados aos filhos (se você não sabe o que são sinais, fique tranquilo, vamos falar disso em breve...)
Processos zumbis: quando um filho termina mas o pai não coleta seu exit status via wait()/waitpid(), o processo permanece como zombie, consumindo uma entrada na tabela de processos
Processos órfãos: filhos cujo pai terminou são "adotados" pelo init/systemd
Grupos de processos e sessões: permitem gerenciar conjuntos de processos relacionados (fundamental para job control em shells e para containers)

[!IMPORTANT]
Implicação prática: Se sua aplicação Python com Gunicorn cria workers via fork(), cada worker é um processo filho. Se o master process morrer inesperadamente sem cleanup adequado, você pode acabar com workers orphans consumindo recursos.

Estados de Processo

Entender o ciclo de vida de um processo vai permitir que você, desenvolvedor backend, perceba por que a performance de sua aplicação pode ser afetada por fatores que estão fora do seu código — como a carga do sistema, a quantidade de processos concorrentes, o comportamento de I/O, etc.

Um processo no Linux transita entre estados bem definidos ao longo de sua vida. A compreensão desses estados é essencial para diagnosticar problemas de performance.

Os cinco estados fundamentais (modelo teórico)

                    ┌─────────────────────────┐
                    │                         │
                    ▼                         │
┌─────┐  admit  ┌───────┐  dispatch ┌─────────┐  exit  ┌────────────┐
│ New │────────►│ Ready │──────────►│ Running │──────► │ Terminated │
└─────┘         └───────┘           └─────────┘        └────────────┘
                    ▲                     │
                    │    I/O or event     │
                    │    completion       │
                    │                     │ I/O or event
                    │                     │ wait
                    │    ┌─────────┐      │
                    └─── │ Blocked │ ◄────┘
                         └─────────┘

New (Criado): o processo está sendo criado pelo kernel. A task_struct está sendo alocada e inicializada.
Ready (Pronto): o processo está em memória, pronto para executar, aguardando que o escalonador lhe atribua a CPU.
Running (Executando): o processo está efetivamente utilizando a CPU, executando instruções.
Blocked (Bloqueado): o processo está aguardando algum evento externo — I/O de disco, resposta de rede, lock de mutex, etc.
Terminated (Terminado): o processo finalizou sua execução, mas sua entrada na tabela de processos ainda existe até que o pai colete o exit status.

Estados no kernel Linux

O kernel Linux implementa esses estados conceituais com granularidade adicional, definidos no campo state da task_struct:

Estado do Kernel	Valor	Significado
`TASK_RUNNING`	0	Processo executando ou na fila de prontos (ready queue)
`TASK_INTERRUPTIBLE`	1	Bloqueado, mas pode ser acordado por sinais
`TASK_UNINTERRUPTIBLE`	2	Bloqueado em I/O crítico, não responde a sinais
`__TASK_STOPPED`	4	Parado por sinal (SIGSTOP, SIGTSTP)
`__TASK_TRACED`	8	Sendo rastreado por debugger (ptrace)
`EXIT_ZOMBIE`	16	Terminado, aguardando `wait()` do pai
`EXIT_DEAD`	32	Estado final antes da remoção
`TASK_IDLE`	—	Idle (kernel 4.21+), similar a UNINTERRUPTIBLE mas não conta como load

A distinção entre TASK_INTERRUPTIBLE e TASK_UNINTERRUPTIBLE é particularmente importante:

Processos em TASK_UNINTERRUPTIBLE (estado D no ps/top) contam para o load average do sistema. Se sua aplicação tem muitos processos nesse estado, geralmente indica problemas de I/O — disco lento, NFS travado, ou storage com latência alta.
Processos em TASK_INTERRUPTIBLE (estado S) são o caso normal de processos aguardando I/O — um servidor web esperando conexões, por exemplo.

# Visualizando estados de processos
$ ps aux | head -5
USER       PID %CPU %MEM    VSZ   RSS TTY STAT START   TIME COMMAND
root         1  0.0  0.1 169536 13312 ?   Ss   May01   0:12 /sbin/init
root         2  0.0  0.0      0     0 ?   S    May01   0:00 [kthreadd]
www-data  1200  2.3  1.5 285432 61440 ?   Sl   09:00   1:45 gunicorn: worker
postgres  1500  0.1  0.8 215000 32768 ?   Ss   May01   0:55 postgres: writer

# STAT column: S=sleeping(interruptible), D=disk sleep(uninterruptible),
#              R=running, T=stopped, Z=zombie, l=multi-threaded, s=session leader

[!TIP]
Dica de diagnóstico: Se o load average do seu servidor está alto, mas a utilização de CPU é baixa, procure processos no estado D (TASK_UNINTERRUPTIBLE). Isso indica gargalo de I/O, não de CPU.

Como um processo é criado?

A criação de um processo no Linux é realizada através da system call fork() ou, mais modernamente, clone(). O processo pai chama fork(), que cria um novo processo filho duplicando o contexto do pai — incluindo código, dados, heap e stack. O filho recebe um novo PID e é colocado na fila de prontos para execução. O processo filho pode então chamar execve() para substituir sua própria imagem por um novo programa, ou pai e filho podem simplesmente continuar executando o mesmo código.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork(); // syscall: duplica o processo atual

    if (pid < 0) {
        // fork() retorna -1 em caso de erro
        perror("fork falhou");
        return EXIT_FAILURE;
    }

    if (pid == 0) {
        // Estamos no processo filho (fork() retorna 0 para o filho)
        printf("[filho] PID=%d, pai PID=%d\n", getpid(), getppid());

        // execve() substitui a imagem do processo pelo programa especificado.
        // A partir daqui, o filho passa a executar /bin/echo.
        char *args[] = { "/bin/echo", "[filho] execve: processo substituído com sucesso", NULL };
        execve("/bin/echo", args, NULL);

        // Só chega aqui se execve() falhar
        perror("execve falhou");
        return EXIT_FAILURE;
    }

    // Estamos no processo pai (fork() retorna o PID do filho para o pai)
    printf("[pai] PID=%d, filho PID=%d\n", getpid(), pid);

    // wait() bloqueia o pai até o filho terminar, evitando processo zumbi
    int status;
    waitpid(pid, &status, 0);
    printf("[pai] filho encerrou com status %d\n", WEXITSTATUS(status));

    return EXIT_SUCCESS;
}

A mesma criação pode ser feita com clone(), que é a syscall de baixo nível usada internamente pelo próprio fork() — com a diferença de que clone() permite controlar exatamente o que será compartilhado entre pai e filho, viabilizando a criação de threads (onde memória, file descriptors e outros recursos são compartilhados):

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sched.h>
#include <sys/types.h>
#include <sys/wait.h>

#define STACK_SIZE (1024 * 1024) // 1 MB de stack para o filho

// Função que será executada pelo processo/thread filho
static int filho_fn(void *arg) {
    printf("[filho] PID=%d, pai PID=%d, arg='%s'\n",
           getpid(), getppid(), (char *)arg);
    return 0;
}

int main(void) {
    // Aloca stack para o filho (clone() exige que o chamador forneça a stack)
    char *stack = malloc(STACK_SIZE);
    if (!stack) {
        perror("malloc falhou");
        return EXIT_FAILURE;
    }

    // clone() recebe um ponteiro para o TOPO da stack (cresce para baixo)
    char *stack_top = stack + STACK_SIZE;

    // Flags controlam o que será compartilhado entre pai e filho.
    // SIGCHLD: sinaliza o pai quando o filho terminar (necessário para waitpid).
    // Sem flags de compartilhamento → comportamento idêntico ao fork().
    pid_t pid = clone(filho_fn, stack_top, SIGCHLD, "dados do pai");

    if (pid < 0) {
        perror("clone falhou");
        free(stack);
        return EXIT_FAILURE;
    }

    printf("[pai] PID=%d, filho PID=%d\n", getpid(), pid);

    int status;
    waitpid(pid, &status, 0);
    printf("[pai] filho encerrou com status %d\n", WEXITSTATUS(status));

    free(stack);
    return EXIT_SUCCESS;
}

Flags do `clone()` e o que cada uma controla

A principal diferença entre fork() e clone() está nas flags que clone() aceita. Elas definem precisamente quais recursos serão compartilhados (e não copiados) entre o processo pai e o filho:

Flag	Efeito
`CLONE_VM`	Compartilha o espaço de memória virtual — pai e filho enxergam as mesmas páginas. Sem essa flag, o kernel aplica Copy-on-Write (CoW).
`CLONE_FS`	Compartilha o contexto de sistema de arquivos (working directory, root, umask).
`CLONE_FILES`	Compartilha a tabela de file descriptors — um `close()` no pai fecha para o filho também.
`CLONE_SIGHAND`	Compartilha os handlers de sinais. Obrigatório junto com `CLONE_VM` para threads POSIX.
`CLONE_THREAD`	Coloca o filho no mesmo thread group do pai (mesmo `tgid`). Necessário para que `getpid()` retorne o mesmo valor em todas as threads.
`CLONE_NEWPID`	Cria um novo namespace de PIDs — a base dos containers (o filho vira PID 1 dentro do namespace).
`CLONE_NEWNET`	Cria um novo namespace de rede — interfaces, rotas e portas isoladas.
`CLONE_NEWNS`	Cria um novo namespace de mount — sistema de arquivos isolado.
`SIGCHLD`	Sinal enviado ao pai quando o filho terminar (necessário para `waitpid()` funcionar).

[!NOTE]
Threads vs Processos no Linux: ao contrário de outros sistemas operacionais, o Linux não tem um conceito de "thread" separado no kernel. Uma thread POSIX é simplesmente um clone() com CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD. A distinção entre processo e thread é feita pelas flags passadas ao clone().

Principais syscalls do ciclo de criação de processos

As syscalls abaixo formam o núcleo do gerenciamento de processos no Linux. Toda linguagem, framework ou runtime que cria processos ou threads passa por alguma combinação delas:

Syscall	Número (x86-64)	Descrição	Quando é usada
`fork()`	57	Duplica o processo atual. Filho herda uma cópia do espaço de endereçamento do pai via Copy-on-Write. Retorna 0 para o filho e o PID do filho para o pai.	Criação de processos filhos (Gunicorn workers, subprocessos de shell)
`clone()`	56	Versão parametrizável de `fork()`. Flags definem o que é compartilhado (memória, FDs, handlers de sinal). Base para criação de threads POSIX e namespaces de containers.	Threads (`pthread_create`), containers (Docker, runc), runtimes de linguagens
`execve()`	59	Substitui a imagem do processo atual por um novo programa. O PID é mantido, mas código, dados, heap e stack são trocados.	Inicialização de qualquer programa: `python app.py`, `./api`, `dotnet MyApi.dll`
`waitpid()`	61	Bloqueia o processo pai até que um filho específico termine, coletando seu exit status. Evita processos zumbi.	Qualquer pai que cria filhos com `fork()` ou `clone()`
`exit_group()`	231	Encerra o processo e todas as suas threads, liberando recursos. É chamada quando `main()` retorna ou quando `exit()` é invocado.	Término normal de qualquer processo
`getpid()`	39	Retorna o PID do processo corrente. Para threads do mesmo grupo, retorna o PID do grupo (TGID).	Diagnóstico, logging, sistemas de lock baseados em PID
`getppid()`	110	Retorna o PID do processo pai. Útil para detectar se o pai morreu (retorna 1 se adotado pelo `init`).	Verificação de "pai vivo" em daemons e supervisores de processo
`kill()`	62	Envia um sinal a um processo ou grupo de processos. Apesar do nome, é usada para qualquer sinal — não apenas para encerramento.	Envio de `SIGTERM`, `SIGKILL`, `SIGHUP` a workers e daemons
`prctl()`	157	Controla comportamentos específicos do processo: nome (`PR_SET_NAME`), comportamento ao morte do pai (`PR_SET_PDEATHSIG`), capacidades, etc.	Nomeação de threads para diagnóstico, hardening de segurança
`setrlimit()`	160	Define limites de recursos do processo: número de FDs abertos, tamanho máximo de stack, uso de CPU, memória, etc.	Configuração de ulimits em servidores, containers (cgroups v1 usa isso indiretamente)

[!TIP]
Como observar essas syscalls em sua aplicação: a ferramenta strace intercepta e exibe todas as syscalls feitas por um processo em tempo real. Para ver o ciclo de criação completo de um processo Python, por exemplo: strace -e trace=fork,clone,execve,waitpid python3 -c "import os; os.fork()". O número da syscall (coluna "Número") corresponde ao valor em rax no momento da instrução syscall em x86-64.

Como sua aplicação é iniciada pelo kernel

Quando você digita python app.py, ./minha-api ou dotnet MyApi.dll no terminal, uma sequência bem definida de eventos acontece antes de qualquer linha do seu código ser executada. Entender esse fluxo ajuda a compreender por que configurações de ambiente, limites de recursos e permissões afetam sua aplicação desde o primeiro instante.

O fluxo geral é sempre o mesmo, independente da linguagem: o shell (ou outro processo pai) chama fork() para se duplicar e, em seguida, o filho chama execve() para substituir sua imagem pelo executável da sua aplicação. O kernel então carrega o binário, configura o espaço de endereçamento e transfere o controle para o ponto de entrada do programa.

Python (`python app.py`)

Ao executar um script Python, o kernel carrega o binário do interpretador (/usr/bin/python3) via execve(). O interpretador é um executável ELF nativo — é ele que vira o processo, não o seu script. A partir daí:

O dynamic linker (ld.so) carrega as bibliotecas compartilhadas do CPython (como libpython3.x.so)
O CPython inicializa seu runtime: configura o GIL, o gerenciador de memória (pymalloc) e o sistema de módulos
O interpretador abre e compila app.py para bytecode (.pyc) em memória
A execução do bytecode começa — somente aqui seu código roda

Todo esse bootstrap acontece antes de a primeira linha do seu app.py ser lida. É por isso que um import pesado no topo do módulo eleva o tempo de inicialização do processo.

Go (`./minha-api`)

Diferente de Python, um binário Go é compilado estaticamente por padrão — não depende de um interpretador. O kernel carrega o ELF diretamente via execve() e:

O dynamic linker tem pouco ou nenhum trabalho (binário estático)
O runtime Go é inicializado: o scheduler M:N é configurado, as threads do SO (M) são criadas via clone() com CLONE_VM | CLONE_THREAD, e as estruturas de goroutines (G) são preparadas
A goroutine principal (main goroutine) é criada e agendada
A função main() do seu pacote main é chamada

O número de threads do SO criadas nesse bootstrap é controlado por GOMAXPROCS (padrão: número de CPUs lógicas disponíveis, respeitando cgroups em containers). Por isso binários Go iniciam tão rapidamente e já nascem prontos para paralelismo real.

.NET (`dotnet MyApi.dll`)

O comando dotnet é o host do CLR — um executável nativo que o kernel carrega via execve(). A DLL com seu código é passada como argumento. O processo de inicialização:

O host carrega o CoreCLR (libcoreclr.so) via dynamic linker
O CLR inicializa o JIT compiler, o Garbage Collector e o ThreadPool
O ThreadPool cria um conjunto inicial de threads do SO via clone() (com CLONE_VM | CLONE_THREAD) prontas para executar work items
O assembly MyApi.dll é carregado, o método Main é localizado, o JIT compila o IL para código nativo e a execução começa

O GC do .NET configura suas gerações de memória e barreiras de escrita durante essa inicialização — o que explica por que o .NET tem um footprint de memória inicial maior do que Go, mas amortiza esse custo ao longo do tempo de vida do processo com otimizações de JIT (tiered compilation).

Resumo comparativo

	Python	Go	.NET
O que o kernel carrega	`python3` (interpretador)	binário ELF nativo	`dotnet` (host CLR)
Seu código chega ao CPU via	interpretação de bytecode	compilação AOT	JIT (tiered compilation)
Threads do SO no startup	1 (+ GIL)	`GOMAXPROCS`	pool inicial do ThreadPool
Paralelismo de CPU real	apenas com `multiprocessing`	goroutines em N threads	`Task`/`Thread` em N threads
Tempo de startup típico	lento (inicialização do runtime + imports)	muito rápido (binário estático)	moderado (JIT warmup)

Process Control Block (PCB): `task_struct` no Linux

O Process Control Block é a estrutura de dados que o kernel mantém para cada processo, contendo todas as informações necessárias para gerenciá-lo. No Linux, essa estrutura é a task_struct, definida em include/linux/sched.h.

A task_struct é uma das maiores estruturas do kernel — com mais de 600 campos em kernels modernos — e inclui:

task_struct
├── Identificação
│   ├── pid          → PID do processo
│   ├── tgid         → Thread Group ID (PID visível em userspace)
│   ├── comm[16]     → Nome do processo (até 16 caracteres)
│   └── cred         → Credenciais (UID, GID, capabilities)
│
├── Estado e Escalonamento
│   ├── state        → Estado atual (RUNNING, INTERRUPTIBLE, etc.)
│   ├── prio         → Prioridade efetiva
│   ├── static_prio  → Prioridade estática (nice value mapeada)
│   ├── normal_prio  → Prioridade normal calculada
│   ├── policy       → Política de escalonamento (SCHED_NORMAL, etc.)
│   ├── se           → Scheduling entity (para CFS)
│   └── cpus_allowed → Máscara de CPUs permitidas (affinity)
│
├── Memória
│   ├── mm           → Descritor de memória (espaço de endereçamento)
│   └── active_mm    → mm ativo (mesmo para kernel threads)
│
├── Hierarquia
│   ├── parent       → Ponteiro para processo pai
│   ├── children     → Lista de processos filhos
│   └── sibling      → Lista de processos irmãos
│
├── Sistema de Arquivos
│   ├── fs           → Informações de filesystem (root dir, cwd)
│   └── files        → Tabela de file descriptors abertos
│
├── Sinais
│   ├── signal       → Estrutura de sinais compartilhada
│   ├── sighand      → Handlers de sinais
│   └── pending      → Sinais pendentes
│
├── Namespaces e cgroups
│   ├── nsproxy      → Referências aos namespaces
│   └── cgroups      → Associação com control groups
│
└── Contabilidade
    ├── utime        → Tempo em modo usuário
    ├── stime        → Tempo em modo kernel
    └── start_time   → Timestamp de criação

Alguns aspectos dessa estrutura são particularmente relevantes para desenvolvedores backend:

pid vs tgid: No kernel, cada thread tem seu próprio pid. Porém, o que o userspace enxerga como PID é na verdade o tgid (Thread Group ID). Todas as threads de um processo compartilham o mesmo tgid. Quando você executa os.getpid() em Python ou Process.GetCurrentProcess().Id em .NET, está obtendo o tgid.

mm (memory descriptor): Processos que compartilham o mesmo mm compartilham o mesmo espaço de endereçamento — é isso que define threads vs processos. Quando clone() é chamado com CLONE_VM, o novo processo/thread compartilha o mm do pai.

files (file descriptor table): Cada processo tem sua própria tabela de file descriptors. Isso significa que o file descriptor 5 no processo A pode apontar para um arquivo completamente diferente do fd 5 no processo B. Threads, por outro lado, compartilham essa tabela quando criadas com CLONE_FILES.

nsproxy e cgroups: Essas são as bases da containerização. Quando sua aplicação roda em Docker/Kubernetes, cada container possui seus próprios namespaces (PID, network, mount, etc.) e está associado a cgroups específicos que limitam CPU, memória e I/O.

Ciclo de Vida de um Processo

A criação e destruição de processos no Linux segue um fluxo bem definido:

Criação: `fork()` e `clone()`

Processo Pai                    Kernel                         Processo Filho
     │                            │                                 │
     │── fork()/clone() ─────────►│                                 │
     │                            │── aloca task_struct             │
     │                            │── copia/compartilha recursos    │
     │                            │── configura espaço de endereço  │
     │                            │   (COW - Copy-on-Write)         │
     │                            │── insere na run queue           │
     │                            │                                 │
     │◄── retorna PID do filho ───│── retorna 0 ───────────────────►│
     │                            │                                 │
     │   (continua execução)      │            (continua execução)  │
     │                            │                                 │

O mecanismo de Copy-on-Write (COW) é uma otimização crucial: ao invés de copiar todo o espaço de endereçamento do pai para o filho (operação cara), o kernel marca as páginas de memória como somente leitura e compartilha-as. Apenas quando um dos processos tenta escrever em uma página, o kernel cria uma cópia privada daquela página específica.

[!WARNING]
Implicação prática para Python: Servidores como Gunicorn no modo pre-fork criam workers via fork(). Graças ao COW, os workers inicialmente compartilham a memória do master process (incluindo o código Python carregado, módulos importados, etc.). Porém, o reference counting do CPython modifica os objetos em memória (incrementando/decrementando contadores), o que aciona o COW e gradualmente duplica as páginas. Isso pode resultar em consumo de memória significativamente maior do que o esperado.

Execução: `exec()`

Frequentemente, após um fork(), o processo filho substitui sua imagem por um novo programa via exec(). Isso:

Descarta o espaço de endereçamento atual
Carrega o novo binário
Inicializa novos segmentos de text, data, BSS, heap e stack
Preserva o PID, file descriptors (exceto os marcados com FD_CLOEXEC), e credenciais

Terminação: `exit()` e `wait()`

Quando um processo termina:

Libera a maioria dos seus recursos (memória, file descriptors, etc.)
Entra no estado EXIT_ZOMBIE — mantendo apenas a task_struct com o exit status
Envia SIGCHLD ao processo pai
O pai coleta o exit status via wait()/waitpid()
O kernel remove a task_struct — o processo deixa de existir

# Detectando processos zombie
$ ps aux | awk '$8 ~ /Z/ {print}'

# Ou com contagem
$ ps aux | awk '$8 ~ /Z/' | wc -l

[!IMPORTANT]
Implicação prática: Se sua aplicação cria processos filhos (via subprocess em Python, Process.Start em .NET, ou os/exec em Go) e não faz wait() adequadamente, você acumulará zombies. Em escala, isso pode esgotar a tabela de processos do sistema (kernel.pid_max).

Visualizando Processos na Prática

Para entender o estado dos processos em um sistema de produção, o kernel expõe informações detalhadas via /proc:

# Informações básicas do processo
$ cat /proc/<pid>/status
Name:   python3
State:  S (sleeping)
Tgid:   1350
Pid:    1350
PPid:   1200
Threads: 4
VmPeak: 285432 kB
VmRSS:  61440 kB
voluntary_ctxt_switches:    15230
nonvoluntary_ctxt_switches: 892

# Mapeamento de memória
$ cat /proc/<pid>/maps | head -5
00400000-00452000 r-xp 00000000 08:01 131074  /usr/bin/python3
00652000-00653000 r--p 00052000 08:01 131074  /usr/bin/python3
00653000-00654000 rw-p 00053000 08:01 131074  /usr/bin/python3
7f8a00000000-7f8a00021000 rw-p 00000000 00:00 0
7f8a04000000-7f8a04001000 rw-p 00000000 00:00 0

# Informações de escalonamento
$ cat /proc/<pid>/sched
python3 (1350, #threads: 4)
---
se.exec_start                      : 1234567890.123456
se.vruntime                        : 987654.321098
se.sum_exec_runtime                : 105678.000000
nr_switches                        : 16122
nr_voluntary_switches              : 15230
nr_involuntary_switches            : 892

O campo voluntary_ctxt_switches vs nonvoluntary_ctxt_switches é revelador:

Voluntary: o processo cedeu a CPU voluntariamente (geralmente por I/O). Alto para servidores I/O-bound — normal.
Involuntary: o kernel forçou a preempção (o processo esgotou seu timeslice). Alto para processos CPU-bound — pode indicar contenção de CPU.

Teoria de Escalonamento

O escalonador (scheduler) é o componente do kernel que responde a uma pergunta aparentemente simples: qual processo deve executar agora? A resposta, no entanto, envolve trade-offs complexos que impactam diretamente a latência das suas APIs, o throughput dos seus workers e a responsividade dos seus serviços.

Por que escalonamento importa para backend?

Considere um servidor com 8 cores rodando:

16 workers Gunicorn servindo uma API REST
4 instâncias de Celery processando tarefas em background
1 processo Redis
1 processo PostgreSQL com múltiplas conexões
Dezenas de processos auxiliares do sistema

São potencialmente centenas de threads competindo por 8 cores. O escalonador precisa decidir, milhares de vezes por segundo, qual thread executa em qual core. Decisões ruins resultam em latência alta, tail latency imprevisível e throughput degradado.

Objetivos do Escalonamento

Todo algoritmo de escalonamento busca otimizar um conjunto de métricas que, frequentemente, são conflitantes entre si:

Métricas fundamentais

Métrica	Definição	Relevância para Backend
Fairness	Distribuição justa de CPU entre processos	Evita que um worker monopolize CPU enquanto outros ficam parados
Efficiency	Manter a CPU ocupada (minimizar idle time)	Maximizar utilização dos cores pagos na cloud
Turnaround time	Tempo total desde submissão até conclusão	Tempo total para processar um batch job ou ETL
Waiting time	Tempo que o processo passa na ready queue	Contribui diretamente para a latência da sua API
Response time	Tempo até a primeira resposta	Crítico para APIs interativas — o usuário percebe esse delay
Throughput	Processos completados por unidade de tempo	Requests/segundo que seu servidor consegue atender

O conflito fundamental

Essas métricas frequentemente se opõem:

Throughput vs Response time: Maximizar throughput favorece processos CPU-bound com timeslices longos (menos overhead de context switch). Minimizar response time favorece timeslices curtos e preempção frequente.
Fairness vs Efficiency: Garantir fairness perfeita exige context switches frequentes, que desperdiçam ciclos de CPU com overhead.
Batch vs Interactive: Jobs de processamento em lote (ETL, relatórios) se beneficiam de execução contínua. Serviços interativos (APIs) precisam de resposta rápida.

Trade-off: Timeslice Size

Timeslice curto (1ms)              Timeslice longo (100ms)
├─ + Melhor response time          ├─ + Maior throughput
├─ + Mais justo                    ├─ + Menos overhead de context switch
├─ - Muito overhead de switching   ├─ - Response time pior
└─ - Menor throughput              └─ - Menos justo (monopolização)

           Sistemas interativos ◄──────────► Batch systems
           (APIs, web servers)                (ETL, ML training)

Implicação prática: Quando você configura o número de workers do Gunicorn ou o tamanho do thread pool do ASP.NET Core, está indiretamente influenciando como o escalonador distribui CPU entre suas threads. Mais workers do que cores disponíveis significa mais competição e mais context switches.

Continua na parte II
Conteudo parcialmente gerado com auxilio de IA generatica (me ajudou organizar tudo isso kkkk)