Is it normal that a user can take down the whole system by using too much memory?

[RW]

On Sun, 3 Jun 2018 21:09:15 +0200
Polytropon wrote:

> On Sat, 02 Jun 2018 19:25:31 -0400, Brennan Vincent wrote:
> > I'm also curious, however, to learn more from an OS design
> > perspective. Why isn't it possible for the kernel to realize it
> > should kill `eatmem` rather than make the system unusable?
> > 
> > Is this a hard problem in general, or just a missing feature in
> > FreeBSD specifically ?  


> Resource control mechanisms are present in FreeBSD, but it takes
> a system administrator with sufficient knowledge and experience
> to decide about the values that will apply - how much RAM can be
> consumed, how many child processes can be spawned, how many files
> can be held open... and so on. There just is no system default
> that can be preconfigured, calculated, assumed, guessed, or
> arbitrarily chosen. No "one size fits all" solution is possible.

Configuration isn't relevant to the question as it's just a way to avoid
reproducing the test conditions.

> Just take the following example:...
> For this example, try to imagine at what stage the kernel should
> interfere. And _should_ it interfere? From the practical point
> of view, everything worked as it was intended and expected.


The OP's program is attempting to dirty many more pages than will fit in
swap+ram. Eventually, as a last resort, the kernel has no alternative
but to start killing processes. The last time I looked it did kill them
largest first which has the best chance of killing a runaway process
first.

When I ran a similar test a few years ago my program would get killed
as expected, large amounts of swap and memory would be freed and the
system would return quickly to normal. The issue here is that the OP
is only seeing this behaviour half the time.