Ok, so a little bit further. This seems to be that stress-ng is
triggering OOMkiller which I'm not sure it should be, unless it's just
really writing a LOT of data to memory.
My setup has been the same on all architectures and I've seen the same
behaviour on Artful deployments on amd64 (Xeon Phi)
The call that invokes stress-ng looks like this:
timeout -s 14 $end_time stress-ng -k --aggressive --verify --timeout
$runtime --$1 0
Where $end_time is the max time before killing stress-ng IF stress-ng
runs longer than the --timeout value. $1, is the stressor invoked, and
as I said above, we r
So over the weekend, I retried with 4.14.0-041400rc6-generic (since
rc7 was not successfully built when I tried this).
This too ended with call traces in the kernel log after runs of stress-
ng.
I only ran our memory stress and system-wide CPU stress tests, both
tests indicated that they passed (
On 3 November 2017 at 19:27, Jeff Lane wrote:
> On Fri, Nov 3, 2017 at 1:13 PM, Joseph Salisbury
> wrote:
>> Do you know which prior kernels did not exhibit this bug? Was it 4.12
>> or earlier?
>
> I "think" it happened with 4.10 as well, but I'm not positive, I ran
> some tests before realizing
On Fri, Nov 3, 2017 at 1:13 PM, Joseph Salisbury
wrote:
> Do you know which prior kernels did not exhibit this bug? Was it 4.12
> or earlier?
I "think" it happened with 4.10 as well, but I'm not positive, I ran
some tests before realizing I was still on 17.04 and upgrading the VM
to 17.10.
> Co
This seems like stress-ng was eating a load of pages and snapd just got
victimized because it was expanding it's memory when there were no free
pages. Oom killer can seem arbitrary like this, I expect there is a
good reason for it.
--
You received this bug notification because you are a member o
Do you know which prior kernels did not exhibit this bug? Was it 4.12
or earlier?
Could you test the mainline kernel to see if this bug is already fixed upstream:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc7
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Also aff
Fix your bot, guys... it tells me logs are missing and to run apport-
collect which just collects the exact same logs ubuntu-bug collected the
first time.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
apport information
** Tags added: apport-collected
** Description changed:
During regression testing on a z/VM instance, I noticed call traces
being dumped to dmesg that seem to be related to stress-ng.
The stress-ng invocation we're using is:
stress-ng --aggressive --verify --timeout
It's possible these are just OOMkiller related, but the first few call
traces seem centered around snapd and I don't notice any OOMKiller
messages until towards the end of the dmesg log.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linu
I'm also not sure why we're hitting the OOM killer either, the memory
config is light, but not light enough that we'd trigger this sort of
thing on other systems, perhaps its s390x specific:
ubuntu@hwe0008:~$ free -m
totalusedfree shared buff/cache available
M
11 matches
Mail list logo
