Semana 4

• Inspeção em lugares onde se usava o get_free_page(). Em especial onde se usava a flag GFP_ATOMIC. Conclusão: nada é feito por essas rotinas para alocar.
• get_free_page() (mm/page_alloc.c).
• do_page_fault() (arch/i386/mm/fault.c). Sem sucesso.

• Teste de alocação das páginas na inicialização do cache. Sucesso.

• Envio de email para lista Linux-MM, lista oficial do gerenciamento de memória para ver se alguém esclarecia o acontecido.

• Teste de substituição do get_free_page() por kmalloc(). O erro continuou.

• Teste de substituição da flag GFP_ATOMIC por GFP_KERNEL. Em princípio acreditamos num possível deadlock, mas funcionou! Algum lugar deve estar liberando páginas além da thread kswapd.

• Envio de outro email para a lista alertando o pessoal da lista sobre esse teste.

• do_try_to_free_pages() (mm/vmscan.c).

• Swap Cache:
  • add_to_swap_cache()
  • delete_from_swap_cache()
  • swap_duplicate()

• get_swap_page() (mm/swapfile.c).

• do_try_to_free_pages() (mm/vmscan.c) tenta diminuir o dcache (cache de diretório, dos inodes).
• shrink_mmap() (mm/filemap.c). Estudo geral de quais páginas do Swap Cache eram retiradas por ele.
• Funções do mm/page_io.c e relação delas com o Swap Cache.

• Hubertus Frank, do IBM Watson Research Center, respondeu o email enviado pelo grupo e enviou o paper sobre o trabalho dele: ``Operating System Support for Fast Hardware Compression of Main Memory Contents'' [].