Por que o OOM-Killer não pode simplesmente matar o processo que exige muito?

É explicado aqui que o OOM-Killer pode ser configurado via overcommit_memorye que:

2 = sem confirmação excessiva. As alocações falham se pedir demais.
0, 1 = confirmação excessiva (heuristicamente ou sempre). Mate alguns processos com base em algumas heurísticas quando muita memória é realmente acessada.

Agora, posso entender completamente isso, mas por que não existe uma opção (ou por que não é o padrão) para matar o próprio processo que realmente tenta acessar muita memória alocada?

linux out-of-memory

— Martin Ba
fonte

E se um processo crítico do sistema solicitar muita memória?

— Lawrence

Em primeiro lugar - ele pode fazer isso. Mas, o maior problema com essa pergunta é que, com toda a probabilidade, se um processo está pedindo memória, ele está sendo executado recentemente - ou, em outras palavras, esse é um novo processo envolvido no processamento muito atual. Você prefere que o OOM permita que seu cliente não aberto por 3 dias permaneça desperdiçando memória do sistema ou prefere que o YouTube realmente carregue algum tempo este ano? linuxatemyram.com

— mikeserv

É isso que a no overcommitopção essencialmente faz. Se um processo solicitar muita memória, ele falhará. Se ele verificar o erro, ele geralmente se matará; caso contrário, provavelmente receberá um erro de segmentação ao tentar desreferenciar o ponteiro nulo que malloc()retorna e ele trava.

— Barmar

Observe que 2 é realmente o no overcommitmodo, de acordo com as fontes citadas (como kernel.org/doc/Documentation/vm/overcommit-accounting ). Acho que vou editar sua pergunta de acordo.

— hans_meine

Considere este cenário:

Você tem 4 GB de memória livre.
Um processo defeituoso aloca 3.999GB.
Você abre um gerenciador de tarefas para eliminar o processo descontrolado. O gerenciador de tarefas aloca 0,002GB.

Se o processo que foi morto foi o último a solicitar memória, seu gerenciador de tarefas foi morto.

Ou:

Você tem 4 GB de memória livre.
Um processo defeituoso aloca 3.999GB.
Você abre um gerenciador de tarefas para eliminar o processo descontrolado. O servidor X aloca 0,002 GB para lidar com a janela do gerenciador de tarefas.

Agora seu servidor X é morto. Não causou o problema; estava apenas "no lugar errado na hora errada". Foi o primeiro processo a alocar mais memória quando não havia mais nada, mas não foi o processo que usou toda a memória para começar.

— user253751
fonte

Para estender seu exemplo, significa que se um processo estivesse consumindo 99,999% da sua memória, você nunca seria capaz de matá-lo, pois qualquer coisa que pudesse matá-lo exigiria memória e, portanto, seria morto antes que o processo incorreto pudesse ser morto!

— Sled

Veja bem, essa é a filosofia do Linux, não um fato necessário. O Windows 3.0 resolveu o problema, tendo memória suficiente reservada para manipulação de OOM, incluindo as caixas de diálogo necessárias.

— MSalters

@MSalters: Isso realmente não se aplica ao exemplo; O exemplo foi sobre um processo que reservou quase toda a memória, ie. não é suficiente para matar o OOM. Obviamente, deve haver memória suficiente reservada para o manuseio do OOM em qualquer sistema operacional. Mas o processo que chama a manipulação do OOM seria o próximo processo que reserva memória, não o que se comporta mal. A menos, claro, você quis dizer que o Windows 3.0 sempre tinha memória suficiente reservada para executar o gerenciador de tarefas ou que o manipulador de OOM sempre solicitava ao usuário que o processo fosse interrompido. (Que! =

— Acabando com

@AleksiTorhamo: Eu realmente quis dizer o último. O Windows 3.0 não tinha um gerenciador de tarefas completo, tinha as famosas telas azuis cuja memória era pré-alocada.

— MSalters