Honestly writing about the OOM killer makes me look very normal

@ljs
I hate the very idea of the OOM killer.

"When very smart people insist on very stupid things".

At most it should be one of a variety of selectable policies.

@ljs out of memory

@dougmerritt nah I don't agree with that now ;)

The OOM killer is absolutely critical to a stable system.

That's a product of the separation between mapping and faulting in memory i.e. overcommit which is highly useful especially for forking so unavoidable.

At that point under extremely severe memory pressure it becomes 'how do we proceed without becoming unstable?'

The OOM killer is the only really sensible path to take at that point unless you prefer a kernel panic.

@dougmerritt now you can argue that less-strict overcommit should never have been permitted (I think windows does not allow this) but too much relies on this now...

cgroups(v2 of course) allow you to have more control over how this goes at least.

And if you're actually having issues with the oom killer, then something in userland that does something before that happens can be a good idea, e.g. like what meta did - https://github.com/facebookincubator/oomd

@ljs
I understand the motivation, but there are other possibilities, like if we registered critical processes not to be killed except as a last resort. For instance.

In general I see it as like all the working set algorithms that people used to experiment with. It was clear from the literature that there could not be a one size fits all, so IMHO there should be a selectable set of algorithms that each server could pick.

It's all related.

@ljs
BTW I am way behind the times, so apologies if some of this is in fact available these days.

@dougmerritt you can use oom_score_adj to stop things from being killed righ tnow :)

There's working set logic in the kernel too.

Generally you should try to avoid getting into situations where the memory pressure gets that bad, but if you can't avoid it, a userland thing is the way to go.

Also the oom killer can be cgroup-specific so you can have quite a lot of control over things atm

@ljs
Thanks; clearly I should catch up on these topics rather than just trotting out ancient opinions.

But wait, learn new things? Hmm, it'll never catch on.

@dougmerritt always tons more to learn, neverending really

@ljs
You're certainly right about that!

Have I complained recently that certain people are writing must-read books? Harumph!!! So annoying.

They should write shitty books so that I can feel self-righteous about not reading them. Clearly.

@dougmerritt I think i can satisfy you on both fronts

@ljs
BTW I tried to push that idea about working set algorithm choice into BSD 4.0 but no one was interested. (Edit: originally for 2BSD actually, but although the 64KB/128K split I/D made it all the more desirable, the existence of only 8 segments made it rather inflexible, so...)

I'm sure you know what it's like to feel stifled.

@ljs
Ha!

BTW you're clearly modest as a person, but don't forget to get over that in order to push sales of your book.

Sales uber alles.

@ljs @lkundrak why not have both