If I type in my shell
x=`yes`, eventually I will get
cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated) because
yes tries to write into
x forever until it runs out of memory. I get a message
cannot allocate <memory> because the kernel's OOM-killer told
xrealloc there are no more bytes to allocate, and that it should exit immediately.
But, when I ask any
game_engine to allocate more graphics memory that does not exist because I have insufficient resources, it turns to my RAM and CPU to allocate the requested memory there instead.
Why doesn't the kernel's OOM-killer ever catch any
game_engine trying to allocate tons of memory, like it does with
That is, if I'm running
game_engine and my user hasn't spawned any new processes since memory-hog
game_engine, why does said
game_engine always succeed in bringing my system to its unresponsive, unrecoverable knees without OOM-killer killing it?
I use game engines as an example because they tend to allocate tons and tons of memory on my poor little integrated card, but this seems to happen with many resource-intensive X processes.
Are there cases under which the OOM-killer is ineffective or not able to revoke a process' memory?