11–20 of 103 posts
I’d say, let the one who tried to allocate memory crash, and if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.
I’d say, let the one who tried to allocate memory crash, and if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.
This is only a viable answer when overcommit is disabled. The problem comes when overcommit is enabled and you find yourself in a position where many programs think they already have memory and yet there is none to give them. If you simply kill the first piece of code that encounters the end of available memory you might take down anything including the kernel itself. Nothing like statically allocating memory can wor…
Earlier quoted context omitted.
> if you’re a critical process like xlock, use statically allocated memory and don’t alloc again. This doesn't save you if someone other allocates and OOM killer chooses you as victim
What is proposed is to not have an OOM killer with a selection process, meaning that the "someone other allocates" would be the one dying.
So the OOM condition can hit any random process, not necessarily one that just tried to allocate. If you don't have some sort of selection, then you would still have an OOM killer, only it will be killing completely at random.
(2004)
echo "-1000" > /proc//oom_score_adj
https://github.com/torvalds/linux/blob/master/include/uapi/l...
I’d say, let the one who tried to allocate memory crash, and if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.
It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.