logoalt Hacker News

sedatkyesterday at 7:01 PM4 repliesview on HN

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.


Replies

Retr0idyesterday at 7:26 PM

Statically allocated memory can still OOM on access, due to overcommit and lazy page table population. What you really want is mlockall(2) (probably with MCL_CURRENT|MCL_ONFAULT followed by madvise with MADV_POPULATE_*)

show 1 reply
feelameeyesterday at 7:11 PM

> 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

show 1 reply
LoganDarkyesterday at 7:04 PM

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 work when overcommit is enabled because the kernel is free to compress memory, page it out and etc. and then murder you the next time you try to perform any operation that it doesn't have the space for, no matter how safe and static your initialization was.

Note that overcommit is very useful in many cases including the ones where swap saves the stability of the system under conditions that would otherwise completely lock up or panic, so it's also not viable to just prevent it from being used.

show 3 replies
amlutoyesterday at 7:38 PM

The fact that xlock crashing unlocks an X11 session is, IMO, pathetic.

show 1 reply