Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

lwn.net

Post reply on HN
Print view View original

31–40 of 103 posts

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#31

Post by muvlon »

tux3 wrote: post #14
hkolk wrote: post #6

Earlier quoted context omitted.

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.

The problem is that Linux has memory overcommit and it will OOM when a process faults a page in, not just when someone allocates memory. 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.

That's true, but critical processes could mlockall() after setup, so their stuff never needs paging in.

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#32

Post by throwaway87543 »

bastawhiz wrote: post #27

Especially in an era where RAM is so expensive, the obvious answer is to simply never use memory. If your data can't fit in the plethora of CPU registers at your disposal, your software is probably too complicated. /s

I see you are an AMD VCACHE enjoyer.

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#33

Post by dooglius »

hyperpape wrote: post #26

I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity. There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

The point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#34

Post by ameliaquining »

hyperpape wrote: post #26

I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity. There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

I read him as arguing that overcommit was a mistake. Of course, he doesn't answer any of the obvious follow-up questions, such as, does fork–exec copy all the process's memory and then immediately throw it away, or what. (One could argue that fork–exec was also a mistake, but it long predates Linux, so this doesn't answer the question of how Torvalds should have designed it.)

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#35

Post by ptx »

FreeBSD has a "protect" command which does something similar to what this asks for – the man page [1] describes it:

"The protect command is used to mark processes as protected. The kernel does not kill protected processes when swap space is exhausted. [...] If you protect a runaway process that allocates all memory the system will deadlock."

[1] https://man.freebsd.org/cgi/man.cgi?query=protect&apropos=0&...

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#36

Post by hackyhacky »

dooglius wrote: post #33
hyperpape wrote: post #26

I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity. There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

The point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem

I agree that that's the point he's making, but I don't see how that would work practically. His attitude is that malloc(1<<63) should immediately crash the system, every time? How is that better?

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#38

Post by yjftsjthsd-h »

LoganDark wrote: post #8
sedatk wrote: post #4

Earlier quoted context omitted.

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).

Yes, Wayland should fix this. Granted, then you have a locked screen that the user may or may not be able to unlock, which is awkward if better.

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#39

Post by Retr0id »

Retr0id wrote: post #11
sedatk wrote: post #2

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.

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_*)

oops MCL_ONFAULT kinda does the opposite of what I wanted - I think if you omit that you can skip the madvise, and mlockall will populate everything for you.

Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

#40

Post by cpgxiii »

hackyhacky wrote: post #36
dooglius wrote: post #33

Earlier quoted context omitted.

The point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem

I agree that that's the point he's making, but I don't see how that would work practically. His attitude is that malloc(1<<63) should immediately crash the system, every time? How is that better?

No, if a process allocates an infeasible amount, malloc fails and the process needs to deal with the failure (which is what already happens, "malloc doesn't fail on Linux" is only really true for smaller-than-page-size allocations). The point being made is that the system should account conservatively for all memory that can be used, not just the optimistic underestimate that overcommit enables (i.e. the plane should always carry enough fuel for contingencies, and landing with extra fuel is a good outcome).
Post reply on HN