These stressors are expected to trigger the OOM killer. The oom
adjustment for the stressor child processes is always adjusted to make
them the first processes to be OOM'd. However, the kernel make's it
choice on what gets OOM'd depending on many factors, so the stressors
may end up triggering other hoggy processes to be OOM'd as well.
This is not a bug, it is expected behaviour. See the stress-ng manual,
it clearly states when a stressors can trigger the OOM killer and how
each stress-ng stressor copes with this, for example:
--brk N
start N workers that grow the data segment by one page at a time
using
multiple brk(2) calls. Each successfully allocated new page is
touched
to ensure it is resident in memory. If an out of memory
condition
occurs then the test will reset the data segment to the point
before
it started and repeat the data segment resizing over again.
The
process adjusts the out of memory setting so that it may be
killed by
the out of memory (OOM) killer before other processes. If
it is
killed by the OOM killer then it will be automatically re-started
by a
monitoring parent process.
I shall close this as it is not a bug. Stress-ng is expected to stress a
kernel to trigger OOMs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729878
Title:
stress-ng triggering oomkiller running brk and stack stressors on all
arches.
To manage notifications about this bug go to:
https://bugs.launchpad.net/stress-ng/+bug/1729878/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
