Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
1–10 of 103 posts
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#2I’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.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#3I’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 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.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#4I’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…
I’m not against taking down the kernel if the situation is that catastrophic. Better than killing the lock screen for sure.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#5I’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.
> 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
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#6I’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.
> 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.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#7(2004)
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#8Earlier quoted context omitted.
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…
I’m not against taking down the kernel if the situation is that catastrophic. Better than killing the lock screen for sure.
IMO if the security of a system depends on the lock screen not crashing then the system is not very secure. Security protocols should never fail open like that; a lock screen should never simply be a layer on top of the authenticated desktop. Windows and macOS get this right. I believe Wayland display managers are also able to get this right (but I haven't checked).
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#9Earlier 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.
Yes, don’t have OOM roulette.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#10Earlier quoted context omitted.
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…
I’m not against taking down the kernel if the situation is that catastrophic. Better than killing the lock screen for sure.
Shouldn't desktop environments detect if a lock screen terminated abnormaly anyway? The OOM killer is just one of many possible causes.