OOM killer eltávolítása a kernelből?

Linux

Egy érdekes thread alakult ki az LKML-en azzal kapcsolatban, hogy Marcelo Tosatti (a jelenlegi stabil Linux kernel széria karbantartója) azt tervezi, hogy beolvasztja Andrea Arcangeli legfrissebb VM munkáját a 2.4-es kernelbe.

Mivel Marcelo nem értette pontosan, hogy milyen változtatásokat szándékozik Andrea véghezvinni, Marcelo kérte, hogy magyarázza el azokat. Többek között arra várt Tosatti magyarázatot, hogy Arcangeli miért távolította el a VM kódból az OOM killert (Out of Memory Killer - része a VM (virtuális memória) kódnak. Feladata, hogy meghatározott rendszerben "lője" ki az alkalmazásokat, ha az operációs rendszer kifut a memóriából, így visszanyerve azt a memóriát, amit a "kilőtt" alkalmazás használt).

Arcangeli szerint az OOM killer kód nem jó, szerinte az OOM killer káros például az adatbázis szerverek működésére, ezért azt eltávolította. Ebből alakult ki a hosszabb diskurzus, amelyben pro és kontra érvek hangzottak el az OOM killer-rel kapcsolatban.

A thread itt kezdődik.

( bitfakk | 2003. 09. 02., k – 13:14 )

Annyira nem latszik bonyolultnak, de en azert nem mernem kikapcsolni. Melyik adatbazis rendszerre karos konkretan? PostgreSQL-nek meg tudod mondani hogy max mennyi memoriat kaphat meg, tobbet nem fog felhasznalni, szerintem a tobbinek is. Mi tortenjen akkor, ha tobb memoria kell a processznek, de mar nincs? Alakuljon ki egy batar nagy deadlock?

( borso | 2003. 09. 02., k – 15:12 )

#ifdef nagyon nem rulez. A patch szerzojenek me'g nem okoz gondot,

de az osszemergelt tree-ben nagyon atlathatatlan ha a kulonallo

developerek ifdefelnek.

Egyebkent mm/oom_kill.c, eljatszadozni tokeletes.

A fo kerdes az hogy mit legyen ha barmilyen okbol kifogysz a swapbol is.

Opciok:

-- adjunk vissza -ENOMEM-et az allokalni probalo alkalmazasnak

problema: nem biztos hogy o a ludas (omiatta allt elo az OOM)

es az -ENOMEM alapvetoen nem old meg semmit, a rendszer ugyanugy

hasznalhatatlan marad

-- SIGKILL valakire

problema: de kire? sshd, dbms, syslogd, X szervert jo lennem nem

eltalalni mert abbol megint csak galiba lesz, emellett az sem biztos

hogy a valodi bunos bunhodni fog. Azt sem ertekeli minden program

ha csak fogod magad es kikilleled (unclean allapotban hagyja a hw-t,

ilyesmik)

-- SIGTERM nehanyszor, majd SIGKILL

problema: ismet nem biztos hogy rossz processt fejezunk le, raadasul

lassu is; de legalabb az aldozatnak van egy csopp eselye rendet

tennie maga utan

A szituaciot negyzetesen bonyolitja ha van memory overcommit; ekkor

a -ENOMEM nem jatszik be (az allokacio korabban mar lezajlott).

Hasonlo a helyzet a stack kifogyasaval is.