* [3.19-final|next-20150204] LTP OOM testsuite causes call-traces
@ 2015-02-10 9:42 Sedat Dilek
2015-02-10 10:45 ` Balbir Singh
0 siblings, 1 reply; 3+ messages in thread
From: Sedat Dilek @ 2015-02-10 9:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, LKML, linux-next
[-- Attachment #1: Type: text/plain, Size: 6850 bytes --]
Hi,
I first noticed call-traces in next-20150204 and tested on v3.19-final
out of curiosity.
So, oom3 | oom4 | oom5 from LTP tests produces call-traces in my logs
in both releases.
Yesterday, I sent a tarball to linux-mm/Shutemov which has material
for next-20150204.
The for-lkml tarball has stuff for v3.19-final.
As an example (please see dmesg files in attached tarball(s)):
...
+[ 143.591734] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 143.591789] oom03 cpuset=/ mems_allowed=0
+[ 143.591828] CPU: 0 PID: 2904 Comm: oom03 Not tainted 3.19.0-1-iniza-small #1
+[ 143.591830] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
+[ 143.591831] ffff880034a64800 ffff880032c57bf8 ffffffff8175c66c
0000000000000008
+[ 143.591835] ffff8800681a54d0 ffff880032c57c88 ffffffff8175ac3a
ffff880032c57c28
+[ 143.591838] ffffffff810c329d 0000000000000206 ffffffff81c74040
ffff880032c57c38
+[ 143.591841] Call Trace:
+[ 143.591848] [<ffffffff8175c66c>] dump_stack+0x4c/0x65
+[ 143.591852] [<ffffffff8175ac3a>] dump_header+0x9e/0x259
+[ 143.591857] [<ffffffff810c329d>] ? trace_hardirqs_on_caller+0x15d/0x200
+[ 143.591860] [<ffffffff810c334d>] ? trace_hardirqs_on+0xd/0x10
+[ 143.591863] [<ffffffff81184cd2>] oom_kill_process+0x1d2/0x3c0
+[ 143.591868] [<ffffffff811ebf40>] mem_cgroup_oom_synchronize+0x630/0x670
+[ 143.591871] [<ffffffff811e6ac0>] ? mem_cgroup_reset+0xb0/0xb0
+[ 143.591874] [<ffffffff81185628>] pagefault_out_of_memory+0x18/0x90
+[ 143.591877] [<ffffffff8106317d>] mm_fault_error+0x8d/0x190
+[ 143.591879] [<ffffffff810637a8>] __do_page_fault+0x528/0x600
+[ 143.591883] [<ffffffff8113a847>] ? __acct_update_integrals+0xb7/0x120
+[ 143.591886] [<ffffffff81765a1b>] ? _raw_spin_unlock+0x2b/0x40
+[ 143.591889] [<ffffffff810a8ac1>] ? vtime_account_user+0x91/0xa0
+[ 143.591892] [<ffffffff8117ff83>] ? context_tracking_user_exit+0xb3/0x110
+[ 143.591895] [<ffffffff810638b1>] do_page_fault+0x31/0x70
+[ 143.591898] [<ffffffff817687b8>] page_fault+0x28/0x30
+[ 143.591934] Task in /1 killed as a result of limit of /1
+[ 143.591940] memory: usage 1048576kB, limit 1048576kB, failcnt 24350
+[ 143.591942] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
+[ 143.591943] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
+[ 143.591944] Memory cgroup stats for /1: cache:0KB rss:1048576KB
rss_huge:0KB mapped_file:0KB writeback:12060KB inactive_anon:524284KB
active_anon:524192KB inactive_file:0KB active_file:0KB unevictable:0KB
+[ 143.592007] [ pid ] uid tgid total_vm rss nr_ptes swapents
oom_score_adj name
+[ 143.592155] [ 2903] 0 2903 1618 436 9 0
0 oom03
+[ 143.592159] [ 2904] 0 2904 788050 245188 616 65535
0 oom03
+[ 143.592162] Memory cgroup out of memory: Kill process 2904 (oom03)
score 921 or sacrifice child
+[ 143.592167] Killed process 2904 (oom03) total-vm:3152200kB,
anon-rss:979724kB, file-rss:1028kB
+[ 144.526653] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 144.526658] oom03 cpuset=/ mems_allowed=0
+[ 144.526665] CPU: 0 PID: 2905 Comm: oom03 Not tainted 3.19.0-1-iniza-small #1
+[ 144.526667] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
+[ 144.526668] ffff880034a64800 ffff8800d24f7bf8 ffffffff8175c66c
0000000000000008
+[ 144.526672] ffff880034a40650 ffff8800d24f7c88 ffffffff8175ac3a
ffff8800d24f7c28
+[ 144.526675] ffffffff810c329d 0000000000000206 ffffffff81c74040
ffff8800d24f7c38
+[ 144.526678] Call Trace:
+[ 144.526687] [<ffffffff8175c66c>] dump_stack+0x4c/0x65
+[ 144.526690] [<ffffffff8175ac3a>] dump_header+0x9e/0x259
+[ 144.526694] [<ffffffff810c329d>] ? trace_hardirqs_on_caller+0x15d/0x200
+[ 144.526697] [<ffffffff810c334d>] ? trace_hardirqs_on+0xd/0x10
+[ 144.526701] [<ffffffff81184cd2>] oom_kill_process+0x1d2/0x3c0
+[ 144.526705] [<ffffffff811ebf40>] mem_cgroup_oom_synchronize+0x630/0x670
+[ 144.526708] [<ffffffff811e6ac0>] ? mem_cgroup_reset+0xb0/0xb0
+[ 144.526711] [<ffffffff81185628>] pagefault_out_of_memory+0x18/0x90
+[ 144.526714] [<ffffffff8106317d>] mm_fault_error+0x8d/0x190
+[ 144.526716] [<ffffffff810637a8>] __do_page_fault+0x528/0x600
+[ 144.526720] [<ffffffff8113a847>] ? __acct_update_integrals+0xb7/0x120
+[ 144.526723] [<ffffffff81765a1b>] ? _raw_spin_unlock+0x2b/0x40
+[ 144.526727] [<ffffffff810a8ac1>] ? vtime_account_user+0x91/0xa0
+[ 144.526730] [<ffffffff8117ff83>] ? context_tracking_user_exit+0xb3/0x110
+[ 144.526733] [<ffffffff810638b1>] do_page_fault+0x31/0x70
+[ 144.526736] [<ffffffff817687b8>] page_fault+0x28/0x30
+[ 144.526739] Task in /1 killed as a result of limit of /1
+[ 144.526744] memory: usage 1048576kB, limit 1048576kB, failcnt 25798
+[ 144.526746] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
+[ 144.526747] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
+[ 144.526748] Memory cgroup stats for /1: cache:0KB rss:1048576KB
rss_huge:0KB mapped_file:0KB writeback:0KB inactive_anon:0KB
active_anon:0KB inactive_file:0KB active_file:0KB
unevictable:1048576KB
+[ 144.526767] [ pid ] uid tgid total_vm rss nr_ptes swapents
oom_score_adj name
+[ 144.526912] [ 2903] 0 2903 1618 424 9 12
0 oom03
+[ 144.526915] [ 2905] 0 2905 788050 262398 522 13
0 oom03
+[ 144.526917] Memory cgroup out of memory: Kill process 2905 (oom03)
score 778 or sacrifice child
+[ 144.526921] Killed process 2905 (oom03) total-vm:3152200kB,
anon-rss:1048564kB, file-rss:1028kB
Not sure if this is problem with the oom-killer.
# grep oom-killer: /tmp/dmesg.diff
+[ 143.591734] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 144.526653] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 148.212919] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 156.769905] mount.ntfs invoked oom-killer: gfp_mask=0x201d0,
order=0, oom_score_adj=0
+[ 163.434898] oom04 invoked oom-killer: gfp_mask=0x280da, order=0,
oom_score_adj=0
+[ 173.034503] oom04 invoked oom-killer: gfp_mask=0x280da, order=0,
oom_score_adj=0
+[ 192.567116] oom05 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 193.821380] oom05 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
+[ 196.917182] oom05 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
LTP here is version 20150119.
I have created a 'mm-oom' testcase (for-lkml tarball) to be placed
into /path/to/ltp/runtest directory.
Then simply run:
root# ./runltp -f mm-oom
Please have a look at this.
If you need additional information, please let me know.
Thanks.
Regards,
- Sedat -
[-- Attachment #2: for-lmkl.tar.gz --]
[-- Type: application/x-gzip, Size: 73937 bytes --]
[-- Attachment #3: for-lmkl.tar.gz.sha256sum --]
[-- Type: application/octet-stream, Size: 82 bytes --]
856354a4ab779d4b15228bb26e13f1b3f08160ffbd5131284ef1469002fd1f8e for-lmkl.tar.gz
[-- Attachment #4: for-shutemov.tar.gz --]
[-- Type: application/x-gzip, Size: 81989 bytes --]
[-- Attachment #5: for-shutemov.tar.gz.sha256sum --]
[-- Type: application/octet-stream, Size: 86 bytes --]
4ed23761a2dff77570425554ba98fc2d5c27ba0c050018f3db12e759cfc1cf14 for-shutemov.tar.gz
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [3.19-final|next-20150204] LTP OOM testsuite causes call-traces
2015-02-10 9:42 [3.19-final|next-20150204] LTP OOM testsuite causes call-traces Sedat Dilek
@ 2015-02-10 10:45 ` Balbir Singh
2015-02-19 23:32 ` Sedat Dilek
0 siblings, 1 reply; 3+ messages in thread
From: Balbir Singh @ 2015-02-10 10:45 UTC (permalink / raw)
To: sedat.dilek; +Cc: Andrew Morton, linux-mm, LKML, linux-next
On Tue, Feb 10, 2015 at 3:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> Hi,
>
> I first noticed call-traces in next-20150204 and tested on v3.19-final
> out of curiosity.
>
> So, oom3 | oom4 | oom5 from LTP tests produces call-traces in my logs
> in both releases.
> Yesterday, I sent a tarball to linux-mm/Shutemov which has material
> for next-20150204.
> The for-lkml tarball has stuff for v3.19-final.
>
> As an example (please see dmesg files in attached tarball(s)):
> ...
> +[ 143.591734] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
> oom_score_adj=0
> +[ 143.591789] oom03 cpuset=/ mems_allowed=0
> +[ 143.591828] CPU: 0 PID: 2904 Comm: oom03 Not tainted 3.19.0-1-iniza-small #1
> +[ 143.591830] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> +[ 143.591831] ffff880034a64800 ffff880032c57bf8 ffffffff8175c66c
> 0000000000000008
> +[ 143.591835] ffff8800681a54d0 ffff880032c57c88 ffffffff8175ac3a
> ffff880032c57c28
> +[ 143.591838] ffffffff810c329d 0000000000000206 ffffffff81c74040
> ffff880032c57c38
> +[ 143.591841] Call Trace:
> +[ 143.591848] [<ffffffff8175c66c>] dump_stack+0x4c/0x65
> +[ 143.591852] [<ffffffff8175ac3a>] dump_header+0x9e/0x259
> +[ 143.591857] [<ffffffff810c329d>] ? trace_hardirqs_on_caller+0x15d/0x200
> +[ 143.591860] [<ffffffff810c334d>] ? trace_hardirqs_on+0xd/0x10
> +[ 143.591863] [<ffffffff81184cd2>] oom_kill_process+0x1d2/0x3c0
> +[ 143.591868] [<ffffffff811ebf40>] mem_cgroup_oom_synchronize+0x630/0x670
> +[ 143.591871] [<ffffffff811e6ac0>] ? mem_cgroup_reset+0xb0/0xb0
> +[ 143.591874] [<ffffffff81185628>] pagefault_out_of_memory+0x18/0x90
> +[ 143.591877] [<ffffffff8106317d>] mm_fault_error+0x8d/0x190
> +[ 143.591879] [<ffffffff810637a8>] __do_page_fault+0x528/0x600
> +[ 143.591883] [<ffffffff8113a847>] ? __acct_update_integrals+0xb7/0x120
> +[ 143.591886] [<ffffffff81765a1b>] ? _raw_spin_unlock+0x2b/0x40
> +[ 143.591889] [<ffffffff810a8ac1>] ? vtime_account_user+0x91/0xa0
> +[ 143.591892] [<ffffffff8117ff83>] ? context_tracking_user_exit+0xb3/0x110
> +[ 143.591895] [<ffffffff810638b1>] do_page_fault+0x31/0x70
> +[ 143.591898] [<ffffffff817687b8>] page_fault+0x28/0x30
> +[ 143.591934] Task in /1 killed as a result of limit of /1
> +[ 143.591940] memory: usage 1048576kB, limit 1048576kB, failcnt 24350
> +[ 143.591942] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
> +[ 143.591943] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
> +[ 143.591944] Memory cgroup stats for /1: cache:0KB rss:1048576KB
> rss_huge:0KB mapped_file:0KB writeback:12060KB inactive_anon:524284KB
> active_anon:524192KB inactive_file:0KB active_file:0KB unevictable:0KB
> +[ 143.592007] [ pid ] uid tgid total_vm rss nr_ptes swapents
> oom_score_adj name
> +[ 143.592155] [ 2903] 0 2903 1618 436 9 0
> 0 oom03
> +[ 143.592159] [ 2904] 0 2904 788050 245188 616 65535
> 0 oom03
> +[ 143.592162] Memory cgroup out of memory: Kill process 2904 (oom03)
> score 921 or sacrifice child
> +[ 143.592167] Killed process 2904 (oom03) total-vm:3152200kB,
> anon-rss:979724kB, file-rss:1028kB
> +[ 144.526653] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
> oom_score_adj=0
Looks like we ran out of memory, the limit is 1024MB (1GiB) and we've
hit it with a fail count of 24350. So basically /1 hit the limit and
got OOM killed. Isn't that what you were testing for? How was the
expected victim?
Thanks,
Balbir Singh.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [3.19-final|next-20150204] LTP OOM testsuite causes call-traces
2015-02-10 10:45 ` Balbir Singh
@ 2015-02-19 23:32 ` Sedat Dilek
0 siblings, 0 replies; 3+ messages in thread
From: Sedat Dilek @ 2015-02-19 23:32 UTC (permalink / raw)
To: Balbir Singh; +Cc: Andrew Morton, linux-mm, LKML, linux-next
On Tue, Feb 10, 2015 at 11:45 AM, Balbir Singh <bsingharora@gmail.com> wrote:
> On Tue, Feb 10, 2015 at 3:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> Hi,
>>
>> I first noticed call-traces in next-20150204 and tested on v3.19-final
>> out of curiosity.
>>
>> So, oom3 | oom4 | oom5 from LTP tests produces call-traces in my logs
>> in both releases.
>> Yesterday, I sent a tarball to linux-mm/Shutemov which has material
>> for next-20150204.
>> The for-lkml tarball has stuff for v3.19-final.
>>
>> As an example (please see dmesg files in attached tarball(s)):
>> ...
>> +[ 143.591734] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
>> oom_score_adj=0
>> +[ 143.591789] oom03 cpuset=/ mems_allowed=0
>> +[ 143.591828] CPU: 0 PID: 2904 Comm: oom03 Not tainted 3.19.0-1-iniza-small #1
>> +[ 143.591830] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> +[ 143.591831] ffff880034a64800 ffff880032c57bf8 ffffffff8175c66c
>> 0000000000000008
>> +[ 143.591835] ffff8800681a54d0 ffff880032c57c88 ffffffff8175ac3a
>> ffff880032c57c28
>> +[ 143.591838] ffffffff810c329d 0000000000000206 ffffffff81c74040
>> ffff880032c57c38
>> +[ 143.591841] Call Trace:
>> +[ 143.591848] [<ffffffff8175c66c>] dump_stack+0x4c/0x65
>> +[ 143.591852] [<ffffffff8175ac3a>] dump_header+0x9e/0x259
>> +[ 143.591857] [<ffffffff810c329d>] ? trace_hardirqs_on_caller+0x15d/0x200
>> +[ 143.591860] [<ffffffff810c334d>] ? trace_hardirqs_on+0xd/0x10
>> +[ 143.591863] [<ffffffff81184cd2>] oom_kill_process+0x1d2/0x3c0
>> +[ 143.591868] [<ffffffff811ebf40>] mem_cgroup_oom_synchronize+0x630/0x670
>> +[ 143.591871] [<ffffffff811e6ac0>] ? mem_cgroup_reset+0xb0/0xb0
>> +[ 143.591874] [<ffffffff81185628>] pagefault_out_of_memory+0x18/0x90
>> +[ 143.591877] [<ffffffff8106317d>] mm_fault_error+0x8d/0x190
>> +[ 143.591879] [<ffffffff810637a8>] __do_page_fault+0x528/0x600
>> +[ 143.591883] [<ffffffff8113a847>] ? __acct_update_integrals+0xb7/0x120
>> +[ 143.591886] [<ffffffff81765a1b>] ? _raw_spin_unlock+0x2b/0x40
>> +[ 143.591889] [<ffffffff810a8ac1>] ? vtime_account_user+0x91/0xa0
>> +[ 143.591892] [<ffffffff8117ff83>] ? context_tracking_user_exit+0xb3/0x110
>> +[ 143.591895] [<ffffffff810638b1>] do_page_fault+0x31/0x70
>> +[ 143.591898] [<ffffffff817687b8>] page_fault+0x28/0x30
>> +[ 143.591934] Task in /1 killed as a result of limit of /1
>> +[ 143.591940] memory: usage 1048576kB, limit 1048576kB, failcnt 24350
>> +[ 143.591942] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
>> +[ 143.591943] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
>> +[ 143.591944] Memory cgroup stats for /1: cache:0KB rss:1048576KB
>> rss_huge:0KB mapped_file:0KB writeback:12060KB inactive_anon:524284KB
>> active_anon:524192KB inactive_file:0KB active_file:0KB unevictable:0KB
>> +[ 143.592007] [ pid ] uid tgid total_vm rss nr_ptes swapents
>> oom_score_adj name
>> +[ 143.592155] [ 2903] 0 2903 1618 436 9 0
>> 0 oom03
>> +[ 143.592159] [ 2904] 0 2904 788050 245188 616 65535
>> 0 oom03
>> +[ 143.592162] Memory cgroup out of memory: Kill process 2904 (oom03)
>> score 921 or sacrifice child
>> +[ 143.592167] Killed process 2904 (oom03) total-vm:3152200kB,
>> anon-rss:979724kB, file-rss:1028kB
>> +[ 144.526653] oom03 invoked oom-killer: gfp_mask=0xd0, order=0,
>> oom_score_adj=0
>
> Looks like we ran out of memory, the limit is 1024MB (1GiB) and we've
> hit it with a fail count of 24350. So basically /1 hit the limit and
> got OOM killed. Isn't that what you were testing for? How was the
> expected victim?
>
You mean that was "expected"?
What do you mean by "How was the expected victim?"?
You need some more informations about my system?
- Sedat -
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-02-19 23:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-10 9:42 [3.19-final|next-20150204] LTP OOM testsuite causes call-traces Sedat Dilek
2015-02-10 10:45 ` Balbir Singh
2015-02-19 23:32 ` Sedat Dilek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox