Perché l'OOM-Killer non può semplicemente uccidere il processo che richiede troppo?

Viene spiegato qui che OOM-Killer può essere configurato tramite overcommit_memorye che:

2 = nessun overcommit. Le allocazioni falliscono se si chiede troppo.
0, 1 = overcommit (euristicamente o sempre). Uccidere alcuni processi basati su alcune euristiche quando si accede a troppa memoria.

Ora, potrei fraintenderlo completamente, ma perché non esiste un'opzione (o perché non è l'impostazione predefinita) per uccidere il processo stesso che tenta effettivamente di accedere a troppa memoria allocata?

linux out-of-memory

— Martin Ba
fonte

Cosa succede se un processo di sistema critico richiede troppa memoria?

— Lawrence,

In primo luogo, può fare questa cosa. Ma il problema più grande con questa domanda è che con ogni probabilità se un processo richiede memoria allora viene di nuovo eseguito - o, in altre parole, si tratta di un nuovo processo coinvolto in un'elaborazione molto attuale. Preferiresti che l'OOM consentisse al tuo client im non aperto per 3 giorni di continuare a sprecare memoria di sistema o preferiresti che YouTube fosse effettivamente caricato un po 'di tempo quest'anno? linuxatemyram.com

— mikeserv il

Questo è ciò che no overcommitessenzialmente fa l' opzione. Se un processo richiede troppa memoria, non riesce. Se verifica l'errore, si ucciderà di solito; in caso contrario, probabilmente otterrà un errore di segmentazione quando tenta di dereferenziare il puntatore null che malloc()ritorna e si arresterà in modo anomalo.

— Barmar,

Si noti che 2 è in realtà la no overcommitmodalità, secondo le fonti citate (come kernel.org/doc/Documentation/vm/overcommit-accounting ). Penso che modificherò la tua domanda di conseguenza.

— hans_meine,

Considera questo scenario:

Hai 4 GB di memoria libera.
Un processo errato alloca 3.999 GB.
Si apre un task manager per terminare il processo in fuga. Il task manager alloca 0,002 GB.

Se il processo che è stato ucciso è stato l'ultimo processo a richiedere memoria, il task manager verrebbe ucciso.

Hai 4 GB di memoria libera.
Un processo errato alloca 3.999 GB.
Si apre un task manager per terminare il processo in fuga. Il server X alloca 0,002 GB per gestire la finestra del task manager.

Ora il tuo server X viene ucciso. Non ha causato il problema; era solo "nel posto sbagliato al momento sbagliato". È capitato di essere il primo processo a allocare più memoria quando non ne rimaneva nessuno, ma non era il processo che utilizzava tutta la memoria per iniziare.

— user253751
fonte

Per estendere il tuo esempio, significa che se un processo consumava il 99,999% della tua memoria non saresti mai in grado di ucciderlo poiché tutto ciò che potrebbe ucciderlo richiederebbe memoria e quindi si ucciderebbe prima che il processo errato potesse essere ucciso!

— Slitta,

Intendiamoci, questa è la filosofia di Linux, non un fatto necessario. Windows 3.0 l'ha risolto avendo sufficiente memoria riservata per la gestione di OOM, incluse le finestre di dialogo necessarie.

— Salterio,

@MSalters: Questo non si applica all'esempio, comunque; L'esempio riguardava un processo che ha riservato quasi tutta la memoria, vale a dire. non abbastanza per farsi uccidere OOM. Ovviamente ci deve essere abbastanza memoria riservata per la gestione OOM su qualsiasi sistema operativo. Ma il processo che invoca la gestione di OOM sarebbe il processo successivo che accade per riservare la memoria, non quello che si comporta male. A meno che, naturalmente, non intendessi dire che Windows 3.0 ha sempre avuto abbastanza memoria riservata per l'esecuzione del task manager o che il gestore OOM ha sempre richiesto all'utente di terminare il processo. (Quale! = Uccidere il processo offensivo)

— Aleksi Torhamo,

@AleksiTorhamo: intendevo davvero quest'ultimo. Windows 3.0 non aveva un task manager completo, aveva le famose schermate blu la cui memoria era preallocata.

— Salteri,