This is not a bug.
It turns out the behaviour I was seeing was due to the fact that swap
accounting is disabled by default and so the perl process was swapping
rather than being killed when its RAM limit was reached.
If I turn swap off (swapoff -a), the process is killed correctly.
Similarly, if
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1303683
Title:
Memory resource controller oom killing not functioning
St
It occurred to me that the behaviour observed could have been due to an
optimisation in a later version of perl, but Ubuntu 13.10 is running
perl v5.14.2 whereas RHEL 7 is running v5.16.3. It seems unlikely,
therefore, that the version of perl is significant to this problem.
--
You received this
Hi Joseph
As per comment #2, this bug reproduced on the latest upstream kernel.
Regards,
Glyn
** Tags added: kernel-bug-exists-upstream
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, whic
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.14 kernel[0].
If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.
If the mainline kernel does not fix t
Note that the above instructions assuming swapping is off, otherwise
memory.memsw.limit_in_bytes would also need to be set to 100.
The above testing was done on a 3.11.0-17-generic kernel. Re-testing on
an upstream kernel, 3.14.0-031400-generic ("3.14-trusty"), showed the
same problem - the pr
6 matches
Mail list logo