Memoria Virtual

Modulo 4 · Aula 2 ~25 min de leitura Nivel: Intermediario

Video da aula estara disponivel em breve

O que e Memoria Virtual?

Memoria virtual e a tecnica que permite que processos usem mais memoria do que a RAM fisicamente disponivel. O SO usa disco (swap) como extensao da RAM, movendo paginas entre RAM e disco de forma transparente para o processo.

Beneficios fundamentais:

Isolamento: cada processo tem seu proprio espaco de enderecamento virtual
Tamanho: processos podem usar mais memoria que a RAM fisica
Compartilhamento: bibliotecas compartilhadas mapeadas uma vez na RAM fisica, visíveis por multiplos processos
Flexibilidade: so carrega em RAM as partes que estao sendo usadas (demand paging)

Tabela de Paginas

A memoria virtual e dividida em blocos de tamanho fixo chamados paginas (tipicamente 4KB). A RAM fisica e dividida em blocos do mesmo tamanho chamados frames. A tabela de paginas mapeia paginas virtuais para frames fisicos.

Diagrama — Tabela de Paginas

Endereco virtual: 0x00005A3C
Pagina = 4KB = 2^12 bytes

Endereco virtual (32 bits):
|---- 20 bits ----|-- 12 bits --|
| numero da pagina|   offset    |
|     0x00005     |    0xA3C    |
       |
       v
Tabela de Paginas (por processo):
+-------+-------+-------+-------+
| Pagina| Frame | Valid | Perms |
+-------+-------+-------+-------+
|   0   |   7   |   1   |  r-x  |
|   1   |   3   |   1   |  rw-  |
|   2   |   -   |   0   |  ---  |  ← nao esta em RAM!
|   3   |  12   |   1   |  rw-  |
|   4   |   -   |   0   |  ---  |  ← nao esta em RAM!
|   5   |   9   |   1   |  rw-  |  ← nossa pagina!
+-------+-------+-------+-------+
       |
       v
Endereco fisico:
| Frame 9 | offset 0xA3C |  =  0x00009A3C

Page size de 4KB: endereco virtual 0x00005A3C
  Pagina 5: 0x00005 * 4096 = byte 20480
  Offset A3C: 2620 bytes dentro da pagina
  Frame 9: 0x00009 * 4096 = byte 36864 na RAM
  Endereco fisico: 36864 + 2620 = 0x00009A3C

TLB — Translation Lookaside Buffer

Consultar a tabela de paginas em cada acesso a memoria seria muito lento (a tabela esta na RAM). A solucao e um cache de hardware chamado TLB:

Diagrama — TLB

CPU gera endereco virtual
          |
          v
    +----------+
    |   TLB    |  Cache associativo de traducoes recentes
    | (64-1024 |  Consulta em ~1 ciclo de clock
    |  entries)|
    +----------+
     /        \
   HIT       MISS
   /            \
Endereco       Consulta Tabela
fisico         de Paginas na RAM
direto!        (~100 ciclos)
               |
               v
          Atualiza TLB
          com nova entrada

TLB Hit Rate tipica: 95-99%
  Com 99% hit rate e TLB de 1 ciclo + tabela de 100 ciclos:
  Tempo medio = 0.99 * 1 + 0.01 * 100 = 1.99 ciclos
  (quase tao rapido quanto acesso direto a RAM!)

TLB flush Quando ocorre um context switch, a TLB do processo antigo e invalida para o novo processo (tabelas de paginas diferentes). O SO faz um TLB flush, descartando todas as entradas. O novo processo comeca com TLB fria, causando muitos misses iniciais. Isso e um custo indireto significativo do context switch.

Page Fault (Falta de Pagina)

Quando a MMU tenta traduzir um endereco e o bit Valid na tabela de paginas e 0, ocorre um page fault. Isso nao e necessariamente um erro — pode significar que a pagina esta em disco (swap) e precisa ser carregada:

Diagrama — Tratamento de Page Fault

1. CPU acessa endereco virtual
2. MMU consulta tabela de paginas: bit Valid = 0
3. Page fault! Trap para o kernel

4. Kernel verifica:
   a) Endereco invalido? -> Segmentation fault (mata o processo)
   b) Pagina em disco (swap)? -> Continua abaixo
   c) Pagina nunca alocada? -> Aloca frame zerado (demand paging)

5. Kernel busca pagina no disco (swap in)
   - Encontra frame livre na RAM
   - Se nao ha frame livre: evict (substitui) uma pagina existente
   - Le pagina do disco para o frame

6. Atualiza tabela de paginas: Valid = 1, Frame = novo frame
7. Reinicia a instrucao que causou o fault

Custo: ~1-10ms (I/O de disco!)
Comparacao: acesso a RAM = ~100ns
Page fault e ~10.000-100.000x mais lento que acesso normal!

Demand Paging

Com demand paging, o SO so carrega uma pagina em RAM quando ela e acessada pela primeira vez. Nao carrega o programa inteiro ao iniciar — apenas as paginas realmente usadas.

Shell — Observando page faults

# Contar page faults de um comando
$ /usr/bin/time -v ls /tmp 2>&1 | grep -i fault
Minor (reclaiming a frame) page faults: 123
Major (requiring I/O) page faults: 0

# Minor fault: pagina nao estava na tabela mas estava em RAM
# Major fault: pagina teve que ser lida do disco (LENTO)

# Ver page faults de um processo rodando
$ cat /proc/1234/stat | awk '{print "Minor:", $10, "Major:", $12}'

# Ver uso de swap do sistema
$ swapon --show
NAME      TYPE      SIZE   USED  PRIO
/dev/sda2 partition   4G   1.2G    -2

$ free -h
              total   used   free  shared  buff/cache  available
Mem:          16Gi   8.2Gi  1.3Gi   234Mi      6.5Gi     7.2Gi
Swap:          4Gi   1.2Gi  2.8Gi

Swap e performance Se o sistema esta fazendo muitos major page faults, provavelmente esta com pouca RAM e usando swap excessivamente. Isso torna o sistema extremamente lento — o disco e 1000x mais lento que RAM. Em servidores de producao, muitos admins configuram vm.swappiness=10 ou ate desabilitam swap para evitar esse cenario.

No harness.os

O Anthropic prompt cache e o TLB do harness.os. A analogia e precisa:

Diagrama — Prompt Cache como TLB

Memoria Virtual (SO)              harness.os
====================              ===========

TLB (hardware cache)              Prompt Cache (Anthropic)
  Hit: ~1 ciclo                     Hit: desconto de tokens
  Miss: ~100 ciclos (tabela RAM)    Miss: custo total de tokens
  Hit rate: 95-99%                  Hit rate: depende da sessao

Tabela de Paginas (RAM)           MCP Tools (Neon DB)
  Mapeamento completo               Knowledge, rules, handoffs
  Consultada em TLB miss             Consultada quando cache miss

Disco (swap)                      Repo de arquivos (Scale 1)
  Armazenamento persistente          CLAUDE.md, rules/, knowledge/
  Lento para acessar                  Lento para ler (file I/O)
  Usado quando RAM insuficiente       Usado quando DB nao tem

Page Fault = Knowledge Miss
  1. Agente precisa de informacao
  2. Nao esta no contexto (TLB miss)
  3. Busca no banco via MCP tool (tabela de paginas)
  4. Se nao esta no banco: busca no repo (swap)
  5. Carrega no contexto (RAM)
  Custo: ~500ms (query) vs ~0ms (ja no contexto)

Python — Prompt cache como TLB

class PromptCacheTLB:
    """Anthropic prompt cache modelado como TLB."""

    def __init__(self):
        self.cached_prefix = None    # tokens cacheados
        self.hits = 0
        self.misses = 0

    def lookup(self, system_prompt):
        if system_prompt == self.cached_prefix:
            self.hits += 1
            return "cache_hit"    # desconto no custo
        else:
            self.misses += 1
            self.cached_prefix = system_prompt
            return "cache_miss"   # custo total

    def hit_rate(self):
        total = self.hits + self.misses
        return self.hits / total if total > 0 else 0

# Estrategia: manter system prompt ESTAVEL entre chamadas
# para maximizar cache hits (como manter TLB quente)

A estrategia de token economy no harness.os e diretamente analoga a gerencia de memoria virtual: carregar apenas o que e necessario (demand paging), manter dados frequentes no cache (TLB), e evitar "swap" (context overflow) a todo custo.

Homework

Execute /usr/bin/time -v com diferentes programas (ls, gcc, firefox) e compare o numero de minor vs major page faults.
Calcule o tempo medio de acesso a memoria com TLB hit rate de 95% (TLB: 1ns, RAM: 100ns, disco: 10ms para major fault).
No harness.os, identifique o equivalente de "demand paging" vs "prefetching": quando e melhor carregar knowledge sob demanda vs antecipar o que o agente vai precisar?

Resumo

Memoria virtual permite processos usarem mais memoria que a RAM fisica
Tabela de paginas mapeia paginas virtuais (4KB) para frames fisicos
TLB e um cache de traducoes: hit rate de 95-99% e essencial para performance
Page fault: pagina nao em RAM, kernel carrega do disco (major) ou aloca (minor)
Demand paging: so carrega paginas quando acessadas pela primeira vez

Verifique seu entendimento

Qual e a consequencia principal de um TLB miss?

O processo e terminado com segmentation fault
A MMU precisa consultar a tabela de paginas na RAM, o que e muito mais lento
A pagina e automaticamente movida para swap
O SO faz context switch para outro processo

Aula anterior4.1 Memoria e Enderecos Proxima aula4.3 Paginacao e Substituicao de Paginas