QA

Motivation¶

OOM (out-of-memory) handling in GNU/Linux is suboptimal and one can come into a thrashing situation easily where it is hard to come out except for rebooting the system. We should have a test procedure to explore the current limits of the systems we develop and even be able to raise feature requests next to bugs.

Acceptance criteria¶

• AC1: We have a testing procedure to induce OOM conditions, at best automatic
• AC2: We understand the current limits of GNU/Linux to be able to create either bug reports or feature requests

Suggestions¶

• Start a https://en.wikipedia.org/wiki/Fork_bomb and try to recover, e.g. in bash :(){ :|:&};: or maybe better a "memory bomb?": https://codegolf.stackexchange.com/a/24488 . might be too synthetic though
• A test for magic-sysrq-f

Further references¶

• https://superuser.com/questions/248707/how-do-i-quickly-stop-a-process-that-is-causing-thrashing-due-to-excess-memory?rq=1
• https://www.reddit.com/r/linux/comments/75gyrz/a_tribute_to_altsysrqf/
• https://unix.stackexchange.com/questions/271765/machine-freezes-once-it-hits-swap-space-under-heavy-load
• https://en.wikipedia.org/wiki/Magic_SysRq_key which for example also mentions what works for s390x over a 3270 console: ^+- followed by the desired key
• https://bugs.launchpad.net/ubuntu/+source/linux/+bug/194676 describes why openSUSE (sic) has many actions disabled by default