I have 14.04 installed with 4.4.0-28 and I can see the following
In the bad case
1. OOM'ing of stress-ng-brk is slow, I can see it making progress -- see tasks being scheduled/console output and sysrq output on Ctrl-o h
2. stress-ng-brk is trying to make progress in OOM, but is heavily contenting for what seems like lru lock
3. The network driver is trying to serve softirq's and fails to process them as allocation fails and does a dump_stack()
In the other case (based on logs and limited testing - kernel 698f415cf5756e320623bdb015a600945743377c for me)
1. OOM proceeds quickly and stress-ng-brk is OOM'd frequently
2. At some point when all stress-ng-brk seem to be OOM'd the test completes
I think the test relies on all stress-ng-brk's to OOM before considering completion (I could be wrong), but in this case progress is slow, but the system is responding. I am going to try the kernel listed here
We believe that the test may require multiple iterations of running for check for consistency of commits.
At this point I think the test will progress and needs longer and progress is slow. I think the expectation is that it needs to complete faster; the system is not lock'd up completely as far as I can tell.
I have 14.04 installed with 4.4.0-28 and I can see the following
In the bad case
1. OOM'ing of stress-ng-brk is slow, I can see it making progress -- see tasks being scheduled/console output and sysrq output on Ctrl-o h
2. stress-ng-brk is trying to make progress in OOM, but is heavily contenting for what seems like lru lock
3. The network driver is trying to serve softirq's and fails to process them as allocation fails and does a dump_stack()
In the other case (based on logs and limited testing - kernel 698f415cf5756e3 20623bdb015a600 945743377c for me)
1. OOM proceeds quickly and stress-ng-brk is OOM'd frequently
2. At some point when all stress-ng-brk seem to be OOM'd the test completes
I think the test relies on all stress-ng-brk's to OOM before considering completion (I could be wrong), but in this case progress is slow, but the system is responding. I am going to try the kernel listed here
We believe that the test may require multiple iterations of running for check for consistency of commits.
At this point I think the test will progress and needs longer and progress is slow. I think the expectation is that it needs to complete faster; the system is not lock'd up completely as far as I can tell.