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

51–60 of 103 posts

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

#51

Post by xyzzy_plugh »

lokar wrote: post #50

I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way: - no system swap - enough memory for core system services set aside in a cgroup for them to use - by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime) - if needed (rare) services can mount some swap in their own cgroup, but very much d…

I agree with your perspective. I certainly agree that swap can be invaluable at times, and is generally a mistake for your run-of-the-mill production services.

It's a nice approach particularly because all OOMs become actionable: there's a bug in a service or a limit is wrong or traffic is changing in an unexpected way.

Systems built this way end up being extremely reliable in my experience.

It's an uphill battle both ways though and not everyone is up for that experience.

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

#53

Post by zinekeller »

ameliaquining wrote: post #34
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.)

> does fork–exec copy all the process's memory

NT: Yes? Why not?

(note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)

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

#54

Post by eqvinox »

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

I don't know why X11 didn't just add an extension that a client can enable saying "if this client exits unexpectedly/uncleanly [without disabling the extension], just kill the X11 session".

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

#55

Post by sankhao »

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 also think the analogy doesn't work. In the plane situation it seems obvious that the luggage should be ejected before passengers, which is what the guy was asking ?

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

#56

Post by 3r7j6qzi9jvnve »

rwmj wrote: post #13

It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.

If it helps, I run ff in systemd-run with memory limits set -- that's usually enough to avoid the problem in the first place (ff does freeze when loading google spreadsheets or whatever heavy UI, so I also have a script to adjust /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/ff-*.scope/memory.max and memory.high at runtime... I should publish my $bindir someday)

    systemd-run --user --scope --unit=ff-$$.scope \
     -p MemoryMax=4G -p MemoryHigh=3G \
     -p MemorySwapMax=0 \
     firejail firefox "$@"

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

#57

Post by adgjlsfhk1 »

zinekeller wrote: post #53
ameliaquining wrote: post #34

Earlier quoted context omitted.

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

> does fork–exec copy all the process's memory NT: Yes? Why not? (note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)

because this is what causes Windows to use ~80% more memory than unixes

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

#58

Post by fragmede »

sankhao wrote: post #55
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 also think the analogy doesn't work. In the plane situation it seems obvious that the luggage should be ejected before passengers, which is what the guy was asking ?

The analogy doesn't work because you can't call fork() on the plane and then it duplicates just the seat for the passenger or pilot that did something different. Also, killing them rather ghastly.

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

#59

Post by tosti »

lokar wrote: post #50

I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way: - no system swap - enough memory for core system services set aside in a cgroup for them to use - by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime) - if needed (rare) services can mount some swap in their own cgroup, but very much d…

Have you disabled swap in the kconfig entirely?

If not, is your vm.swapiness 0? How do you deal with overcommit? Did you replace malloc with a more strict implementation?

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

#60

Post by tosti »

adgjlsfhk1 wrote: post #57
zinekeller wrote: post #53

Earlier quoted context omitted.

> does fork–exec copy all the process's memory NT: Yes? Why not? (note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)

because this is what causes Windows to use ~80% more memory than unixes

Processes are usually spawned with CreateProcess. There's no fork in win32.
Post reply on HN