A configuração overcommit_memory
é levada em conta em três locais no subsistema de gerenciamento de memória.
-
O principal deles é
__vm_enough_memory
emmm/util.c
, que decide se há memória suficiente disponível para permitir que uma alocação de memória continue (observe que essa é uma função de utilidade que não é necessariamente invocada). Seovercommit_memory
for 1, essa função sempre será bem-sucedida. Se é 2, verifica a memória disponível real. Se é 0, usa a famosa heurística que você menciona; que procede da seguinte forma:- conta o número de páginas gratuitas
- adiciona o número de páginas lastreadas em arquivos (elas podem ser recuperadas)
- remover páginas usadas para memória compartilhada
- adicionar páginas de troca
- adicionar páginas recuperáveis
- conta para páginas reservadas
- deixe alguma memória para o root (se a alocação não estiver sendo feita por um processo
cap_sys_admin
)
O total resultante é usado como o limite para alocações de memória.
-
mmap
também verifica a configuração:MAP_NORESERVE
é honrado se permissão excessiva for permitida (modos 0 e 1) e resultar em alocações sem troca de apoio (VM_NORESERVE
). Neste caso particular, o modo 0 é efetivamente equivalente ao modo 1; isso é o que “chamadas demmap(2)
comMAP_NORESERVE
não são verificadas” está se referindo a: significa queMAP_NORESERVE
mmap
chamadas sempre serão bem-sucedidas e a superalocação resultará na invasão de OOM-killer após o fato, ou uma violação de segmento quando uma gravação é tentada. -
shmem
tem um comportamento semelhante aommap
.
A falta de espaço de endereço deve causar falhas de alocação, não as mortes por OOM, pois a alocação não pode continuar.