From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Johannes Weiner <hannes@cmpxchg.org>,
oleg@redhat.com, xfs@oss.sgi.com, mhocko@suse.cz,
linux-mm@kvack.org, mgorman@suse.de, dchinner@redhat.com,
rientjes@google.com, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: How to handle TIF_MEMDIE stalls?
Date: Mon, 2 Mar 2015 07:46:26 -0500 [thread overview]
Message-ID: <20150302124626.GA25593@laptop.bfoster> (raw)
In-Reply-To: <20150302001723.GO4251@dastard>
On Mon, Mar 02, 2015 at 11:17:23AM +1100, Dave Chinner wrote:
> On Mon, Mar 02, 2015 at 08:48:05AM +1100, Dave Chinner wrote:
> > On Sat, Feb 28, 2015 at 05:15:58PM -0500, Johannes Weiner wrote:
> > > On Sat, Feb 28, 2015 at 11:41:58AM -0500, Theodore Ts'o wrote:
> > > > On Sat, Feb 28, 2015 at 11:29:43AM -0500, Johannes Weiner wrote:
> > > > >
> > > > > I'm trying to figure out if the current nofail allocators can get
> > > > > their memory needs figured out beforehand. And reliably so - what
> > > > > good are estimates that are right 90% of the time, when failing the
> > > > > allocation means corrupting user data? What is the contingency plan?
> > > >
> > > > In the ideal world, we can figure out the exact memory needs
> > > > beforehand. But we live in an imperfect world, and given that block
> > > > devices *also* need memory, the answer is "of course not". We can't
> > > > be perfect. But we can least give some kind of hint, and we can offer
> > > > to wait before we get into a situation where we need to loop in
> > > > GFP_NOWAIT --- which is the contingency/fallback plan.
> > >
> > > Overestimating should be fine, the result would a bit of false memory
> > > pressure. But underestimating and looping can't be an option or the
> > > original lockups will still be there. We need to guarantee forward
> > > progress or the problem is somewhat mitigated at best - only now with
> > > quite a bit more complexity in the allocator and the filesystems.
> >
> > The additional complexity in XFS is actually quite minor, and
> > initial "rough worst case" memory usage estimates are not that hard
> > to measure....
>
> And, just to point out that the OOM killer can be invoked without a
> single transaction-based filesystem ENOMEM failure, here's what
> xfs/084 does on 4.0-rc1:
>
> [ 148.820369] resvtest invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
> [ 148.822113] resvtest cpuset=/ mems_allowed=0
> [ 148.823124] CPU: 0 PID: 4342 Comm: resvtest Not tainted 4.0.0-rc1-dgc+ #825
> [ 148.824648] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> [ 148.826471] 0000000000000000 ffff88003ba2b988 ffffffff81dcb570 000000000000000c
> [ 148.828220] ffff88003bb06380 ffff88003ba2ba08 ffffffff81dc5c2f 0000000000000000
> [ 148.829958] 0000000000000000 ffff88003ba2b9a8 0000000000000206 ffff88003ba2b9d8
> [ 148.831734] Call Trace:
> [ 148.832325] [<ffffffff81dcb570>] dump_stack+0x4c/0x65
> [ 148.833493] [<ffffffff81dc5c2f>] dump_header.isra.12+0x79/0x1cb
> [ 148.834855] [<ffffffff8117db69>] oom_kill_process+0x1c9/0x3b0
> [ 148.836195] [<ffffffff810a7105>] ? has_capability_noaudit+0x25/0x40
> [ 148.837633] [<ffffffff8117e0c5>] __out_of_memory+0x315/0x500
> [ 148.838925] [<ffffffff8117e44b>] out_of_memory+0x5b/0x80
> [ 148.840162] [<ffffffff811830d9>] __alloc_pages_nodemask+0x7d9/0x810
> [ 148.841592] [<ffffffff811c0531>] alloc_pages_current+0x91/0x100
> [ 148.842950] [<ffffffff8117a427>] __page_cache_alloc+0xa7/0xc0
> [ 148.844286] [<ffffffff8117c688>] filemap_fault+0x1b8/0x420
> [ 148.845545] [<ffffffff811a05ed>] __do_fault+0x3d/0x70
> [ 148.846706] [<ffffffff811a4478>] handle_mm_fault+0x988/0x1230
> [ 148.848042] [<ffffffff81090305>] __do_page_fault+0x1a5/0x460
> [ 148.849333] [<ffffffff81090675>] trace_do_page_fault+0x45/0x130
> [ 148.850681] [<ffffffff8108b8ce>] do_async_page_fault+0x1e/0xd0
> [ 148.852025] [<ffffffff81dd1567>] ? schedule+0x37/0x90
> [ 148.853187] [<ffffffff81dd8b88>] async_page_fault+0x28/0x30
> [ 148.854456] Mem-Info:
> [ 148.854986] Node 0 DMA per-cpu:
> [ 148.855727] CPU 0: hi: 0, btch: 1 usd: 0
> [ 148.856820] Node 0 DMA32 per-cpu:
> [ 148.857600] CPU 0: hi: 186, btch: 31 usd: 0
> [ 148.858688] active_anon:119251 inactive_anon:119329 isolated_anon:0
> [ 148.858688] active_file:19 inactive_file:2 isolated_file:0
> [ 148.858688] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 148.858688] free:1965 slab_reclaimable:2816 slab_unreclaimable:2184
> [ 148.858688] mapped:3 shmem:2 pagetables:1259 bounce:0
> [ 148.858688] free_cma:0
> [ 148.865606] Node 0 DMA free:3916kB min:60kB low:72kB high:88kB active_anon:5100kB inactive_anon:5324kB active_file:0kB inactive_file:8kB unevictable:0kB isolated(as
> [ 148.874431] lowmem_reserve[]: 0 966 966 966
> [ 148.875504] Node 0 DMA32 free:3944kB min:3944kB low:4928kB high:5916kB active_anon:471904kB inactive_anon:471992kB active_file:76kB inactive_file:0kB unevictable:0s
> [ 148.884817] lowmem_reserve[]: 0 0 0 0
> [ 148.885770] Node 0 DMA: 1*4kB (M) 1*8kB (U) 2*16kB (UM) 3*32kB (UM) 1*64kB (M) 1*128kB (M) 0*256kB 1*512kB (M) 1*1024kB (M) 1*2048kB (R) 0*4096kB = 3916kB
> [ 148.889385] Node 0 DMA32: 8*4kB (UEM) 2*8kB (UR) 3*16kB (M) 1*32kB (M) 2*64kB (MR) 1*128kB (R) 0*256kB 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3968kB
> [ 148.893068] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
> [ 148.894949] 47361 total pagecache pages
> [ 148.895816] 47334 pages in swap cache
> [ 148.896657] Swap cache stats: add 124669, delete 77335, find 83/169
> [ 148.898057] Free swap = 0kB
> [ 148.898714] Total swap = 497976kB
> [ 148.899470] 262044 pages RAM
> [ 148.900145] 0 pages HighMem/MovableOnly
> [ 148.901006] 10253 pages reserved
> [ 148.901735] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
> [ 148.903637] [ 1204] 0 1204 6039 1 15 3 163 -1000 udevd
> [ 148.905571] [ 1323] 0 1323 6038 1 14 3 165 -1000 udevd
> [ 148.907499] [ 1324] 0 1324 6038 1 14 3 164 -1000 udevd
> [ 148.909439] [ 2176] 0 2176 2524 0 6 2 571 0 dhclient
> [ 148.911427] [ 2227] 0 2227 9267 0 22 3 95 0 rpcbind
> [ 148.913392] [ 2632] 0 2632 64981 30 29 3 136 0 rsyslogd
> [ 148.915391] [ 2686] 0 2686 1062 1 6 3 36 0 acpid
> [ 148.917325] [ 2826] 0 2826 4753 0 12 2 44 0 atd
> [ 148.919209] [ 2877] 0 2877 6473 0 17 3 66 0 cron
> [ 148.921120] [ 2911] 104 2911 7078 1 17 3 81 0 dbus-daemon
> [ 148.923150] [ 3591] 0 3591 13731 0 28 2 165 -1000 sshd
> [ 148.925073] [ 3603] 0 3603 22024 0 43 2 215 0 winbindd
> [ 148.927066] [ 3612] 0 3612 22024 0 42 2 216 0 winbindd
> [ 148.929062] [ 3636] 0 3636 3722 1 11 3 41 0 getty
> [ 148.930981] [ 3637] 0 3637 3722 1 11 3 40 0 getty
> [ 148.932915] [ 3638] 0 3638 3722 1 11 3 39 0 getty
> [ 148.934835] [ 3639] 0 3639 3722 1 11 3 40 0 getty
> [ 148.936789] [ 3640] 0 3640 3722 1 11 3 40 0 getty
> [ 148.938704] [ 3641] 0 3641 3722 1 10 3 38 0 getty
> [ 148.940635] [ 3642] 0 3642 3677 1 11 3 40 0 getty
> [ 148.942550] [ 3643] 0 3643 25894 2 52 2 248 0 sshd
> [ 148.944469] [ 3649] 0 3649 146652 1 35 4 320 0 console-kit-dae
> [ 148.946578] [ 3716] 0 3716 48287 1 31 4 171 0 polkitd
> [ 148.948552] [ 3722] 1000 3722 25894 0 51 2 250 0 sshd
> [ 148.950457] [ 3723] 1000 3723 5435 3 15 3 495 0 bash
> [ 148.952375] [ 3742] 0 3742 17157 1 37 2 160 0 sudo
> [ 148.954275] [ 3743] 0 3743 3365 1 11 3 516 0 check
> [ 148.956229] [ 4130] 0 4130 3334 1 11 3 484 0 084
> [ 148.958108] [ 4342] 0 4342 314556 191159 619 4 119808 0 resvtest
> [ 148.960104] [ 4343] 0 4343 3334 0 11 3 485 0 084
> [ 148.961990] [ 4344] 0 4344 3334 0 11 3 485 0 084
> [ 148.963876] [ 4345] 0 4345 3305 0 11 3 36 0 sed
> [ 148.965766] [ 4346] 0 4346 3305 0 11 3 37 0 sed
> [ 148.967652] Out of memory: Kill process 4342 (resvtest) score 803 or sacrifice child
> [ 148.969390] Killed process 4342 (resvtest) total-vm:1258224kB, anon-rss:764636kB, file-rss:0kB
> [ 149.415288] XFS (vda): Unmounting Filesystem
> [ 150.211229] XFS (vda): Mounting V5 Filesystem
> [ 150.292092] XFS (vda): Ending clean mount
> [ 150.342307] XFS (vda): Unmounting Filesystem
> [ 150.346522] XFS (vdb): Unmounting Filesystem
> [ 151.264135] XFS: kmalloc allocations by trans type
> [ 151.265195] XFS: 3: count 7, bytes 3992, fails 0, max_size 1024
> [ 151.266479] XFS: 4: count 3, bytes 400, fails 0, max_size 144
> [ 151.267735] XFS: 7: count 9, bytes 2784, fails 0, max_size 536
> [ 151.269022] XFS: 16: count 1, bytes 696, fails 0, max_size 696
> [ 151.270286] XFS: 26: count 1, bytes 384, fails 0, max_size 384
> [ 151.271550] XFS: 35: count 1, bytes 696, fails 0, max_size 696
> [ 151.272833] XFS: slab allocations by trans type
> [ 151.273818] XFS: 3: count 22, bytes 0, fails 0, max_size 0
> [ 151.275010] XFS: 4: count 13, bytes 0, fails 0, max_size 0
> [ 151.276212] XFS: 7: count 12, bytes 0, fails 0, max_size 0
> [ 151.277406] XFS: 15: count 2, bytes 0, fails 0, max_size 0
> [ 151.278595] XFS: 16: count 10, bytes 0, fails 0, max_size 0
> [ 151.279854] XFS: 18: count 2, bytes 0, fails 0, max_size 0
> [ 151.281080] XFS: 26: count 3, bytes 0, fails 0, max_size 0
> [ 151.282275] XFS: 35: count 2, bytes 0, fails 0, max_size 0
> [ 151.283476] XFS: vmalloc allocations by trans type
> [ 151.284535] XFS: page allocations by trans type
>
> Those XFS allocation stats are largest measured allocations done
> under transaction context broken down by allocation and transaction
> type. No failures that would result in looping, even though the
> system invoked the OOM killer on a filesystem workload....
>
> I need to break the slab allocations down further by cache (other
> workloads are generating over 50 slab allocations per transaction),
> but another hour's work and a few days of observation of the stats
> in my normal day-to-day work wll get me all the information I need
> to do a decent first pass at memory reservation requirements for
> XFS.
>
This sounds like something that would serve us well under sysfs,
particularly if we do adopt the kind of reservation model being
discussed in this thread. I wouldn't expect these values to change
drastically or that often, but they could certainly adjust over time to
the point of being out of line with a reservation. A tool like this
combined with Johannes' idea of a warning or something along those lines
for a reservation overrun should give us all we need to identify
something is wrong and have the ability to fix it.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> --
> 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>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Theodore Ts'o <tytso@mit.edu>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
dchinner@redhat.com, oleg@redhat.com, xfs@oss.sgi.com,
mhocko@suse.cz, linux-mm@kvack.org, mgorman@suse.de,
rientjes@google.com, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: How to handle TIF_MEMDIE stalls?
Date: Mon, 2 Mar 2015 07:46:26 -0500 [thread overview]
Message-ID: <20150302124626.GA25593@laptop.bfoster> (raw)
In-Reply-To: <20150302001723.GO4251@dastard>
On Mon, Mar 02, 2015 at 11:17:23AM +1100, Dave Chinner wrote:
> On Mon, Mar 02, 2015 at 08:48:05AM +1100, Dave Chinner wrote:
> > On Sat, Feb 28, 2015 at 05:15:58PM -0500, Johannes Weiner wrote:
> > > On Sat, Feb 28, 2015 at 11:41:58AM -0500, Theodore Ts'o wrote:
> > > > On Sat, Feb 28, 2015 at 11:29:43AM -0500, Johannes Weiner wrote:
> > > > >
> > > > > I'm trying to figure out if the current nofail allocators can get
> > > > > their memory needs figured out beforehand. And reliably so - what
> > > > > good are estimates that are right 90% of the time, when failing the
> > > > > allocation means corrupting user data? What is the contingency plan?
> > > >
> > > > In the ideal world, we can figure out the exact memory needs
> > > > beforehand. But we live in an imperfect world, and given that block
> > > > devices *also* need memory, the answer is "of course not". We can't
> > > > be perfect. But we can least give some kind of hint, and we can offer
> > > > to wait before we get into a situation where we need to loop in
> > > > GFP_NOWAIT --- which is the contingency/fallback plan.
> > >
> > > Overestimating should be fine, the result would a bit of false memory
> > > pressure. But underestimating and looping can't be an option or the
> > > original lockups will still be there. We need to guarantee forward
> > > progress or the problem is somewhat mitigated at best - only now with
> > > quite a bit more complexity in the allocator and the filesystems.
> >
> > The additional complexity in XFS is actually quite minor, and
> > initial "rough worst case" memory usage estimates are not that hard
> > to measure....
>
> And, just to point out that the OOM killer can be invoked without a
> single transaction-based filesystem ENOMEM failure, here's what
> xfs/084 does on 4.0-rc1:
>
> [ 148.820369] resvtest invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
> [ 148.822113] resvtest cpuset=/ mems_allowed=0
> [ 148.823124] CPU: 0 PID: 4342 Comm: resvtest Not tainted 4.0.0-rc1-dgc+ #825
> [ 148.824648] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> [ 148.826471] 0000000000000000 ffff88003ba2b988 ffffffff81dcb570 000000000000000c
> [ 148.828220] ffff88003bb06380 ffff88003ba2ba08 ffffffff81dc5c2f 0000000000000000
> [ 148.829958] 0000000000000000 ffff88003ba2b9a8 0000000000000206 ffff88003ba2b9d8
> [ 148.831734] Call Trace:
> [ 148.832325] [<ffffffff81dcb570>] dump_stack+0x4c/0x65
> [ 148.833493] [<ffffffff81dc5c2f>] dump_header.isra.12+0x79/0x1cb
> [ 148.834855] [<ffffffff8117db69>] oom_kill_process+0x1c9/0x3b0
> [ 148.836195] [<ffffffff810a7105>] ? has_capability_noaudit+0x25/0x40
> [ 148.837633] [<ffffffff8117e0c5>] __out_of_memory+0x315/0x500
> [ 148.838925] [<ffffffff8117e44b>] out_of_memory+0x5b/0x80
> [ 148.840162] [<ffffffff811830d9>] __alloc_pages_nodemask+0x7d9/0x810
> [ 148.841592] [<ffffffff811c0531>] alloc_pages_current+0x91/0x100
> [ 148.842950] [<ffffffff8117a427>] __page_cache_alloc+0xa7/0xc0
> [ 148.844286] [<ffffffff8117c688>] filemap_fault+0x1b8/0x420
> [ 148.845545] [<ffffffff811a05ed>] __do_fault+0x3d/0x70
> [ 148.846706] [<ffffffff811a4478>] handle_mm_fault+0x988/0x1230
> [ 148.848042] [<ffffffff81090305>] __do_page_fault+0x1a5/0x460
> [ 148.849333] [<ffffffff81090675>] trace_do_page_fault+0x45/0x130
> [ 148.850681] [<ffffffff8108b8ce>] do_async_page_fault+0x1e/0xd0
> [ 148.852025] [<ffffffff81dd1567>] ? schedule+0x37/0x90
> [ 148.853187] [<ffffffff81dd8b88>] async_page_fault+0x28/0x30
> [ 148.854456] Mem-Info:
> [ 148.854986] Node 0 DMA per-cpu:
> [ 148.855727] CPU 0: hi: 0, btch: 1 usd: 0
> [ 148.856820] Node 0 DMA32 per-cpu:
> [ 148.857600] CPU 0: hi: 186, btch: 31 usd: 0
> [ 148.858688] active_anon:119251 inactive_anon:119329 isolated_anon:0
> [ 148.858688] active_file:19 inactive_file:2 isolated_file:0
> [ 148.858688] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 148.858688] free:1965 slab_reclaimable:2816 slab_unreclaimable:2184
> [ 148.858688] mapped:3 shmem:2 pagetables:1259 bounce:0
> [ 148.858688] free_cma:0
> [ 148.865606] Node 0 DMA free:3916kB min:60kB low:72kB high:88kB active_anon:5100kB inactive_anon:5324kB active_file:0kB inactive_file:8kB unevictable:0kB isolated(as
> [ 148.874431] lowmem_reserve[]: 0 966 966 966
> [ 148.875504] Node 0 DMA32 free:3944kB min:3944kB low:4928kB high:5916kB active_anon:471904kB inactive_anon:471992kB active_file:76kB inactive_file:0kB unevictable:0s
> [ 148.884817] lowmem_reserve[]: 0 0 0 0
> [ 148.885770] Node 0 DMA: 1*4kB (M) 1*8kB (U) 2*16kB (UM) 3*32kB (UM) 1*64kB (M) 1*128kB (M) 0*256kB 1*512kB (M) 1*1024kB (M) 1*2048kB (R) 0*4096kB = 3916kB
> [ 148.889385] Node 0 DMA32: 8*4kB (UEM) 2*8kB (UR) 3*16kB (M) 1*32kB (M) 2*64kB (MR) 1*128kB (R) 0*256kB 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3968kB
> [ 148.893068] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
> [ 148.894949] 47361 total pagecache pages
> [ 148.895816] 47334 pages in swap cache
> [ 148.896657] Swap cache stats: add 124669, delete 77335, find 83/169
> [ 148.898057] Free swap = 0kB
> [ 148.898714] Total swap = 497976kB
> [ 148.899470] 262044 pages RAM
> [ 148.900145] 0 pages HighMem/MovableOnly
> [ 148.901006] 10253 pages reserved
> [ 148.901735] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
> [ 148.903637] [ 1204] 0 1204 6039 1 15 3 163 -1000 udevd
> [ 148.905571] [ 1323] 0 1323 6038 1 14 3 165 -1000 udevd
> [ 148.907499] [ 1324] 0 1324 6038 1 14 3 164 -1000 udevd
> [ 148.909439] [ 2176] 0 2176 2524 0 6 2 571 0 dhclient
> [ 148.911427] [ 2227] 0 2227 9267 0 22 3 95 0 rpcbind
> [ 148.913392] [ 2632] 0 2632 64981 30 29 3 136 0 rsyslogd
> [ 148.915391] [ 2686] 0 2686 1062 1 6 3 36 0 acpid
> [ 148.917325] [ 2826] 0 2826 4753 0 12 2 44 0 atd
> [ 148.919209] [ 2877] 0 2877 6473 0 17 3 66 0 cron
> [ 148.921120] [ 2911] 104 2911 7078 1 17 3 81 0 dbus-daemon
> [ 148.923150] [ 3591] 0 3591 13731 0 28 2 165 -1000 sshd
> [ 148.925073] [ 3603] 0 3603 22024 0 43 2 215 0 winbindd
> [ 148.927066] [ 3612] 0 3612 22024 0 42 2 216 0 winbindd
> [ 148.929062] [ 3636] 0 3636 3722 1 11 3 41 0 getty
> [ 148.930981] [ 3637] 0 3637 3722 1 11 3 40 0 getty
> [ 148.932915] [ 3638] 0 3638 3722 1 11 3 39 0 getty
> [ 148.934835] [ 3639] 0 3639 3722 1 11 3 40 0 getty
> [ 148.936789] [ 3640] 0 3640 3722 1 11 3 40 0 getty
> [ 148.938704] [ 3641] 0 3641 3722 1 10 3 38 0 getty
> [ 148.940635] [ 3642] 0 3642 3677 1 11 3 40 0 getty
> [ 148.942550] [ 3643] 0 3643 25894 2 52 2 248 0 sshd
> [ 148.944469] [ 3649] 0 3649 146652 1 35 4 320 0 console-kit-dae
> [ 148.946578] [ 3716] 0 3716 48287 1 31 4 171 0 polkitd
> [ 148.948552] [ 3722] 1000 3722 25894 0 51 2 250 0 sshd
> [ 148.950457] [ 3723] 1000 3723 5435 3 15 3 495 0 bash
> [ 148.952375] [ 3742] 0 3742 17157 1 37 2 160 0 sudo
> [ 148.954275] [ 3743] 0 3743 3365 1 11 3 516 0 check
> [ 148.956229] [ 4130] 0 4130 3334 1 11 3 484 0 084
> [ 148.958108] [ 4342] 0 4342 314556 191159 619 4 119808 0 resvtest
> [ 148.960104] [ 4343] 0 4343 3334 0 11 3 485 0 084
> [ 148.961990] [ 4344] 0 4344 3334 0 11 3 485 0 084
> [ 148.963876] [ 4345] 0 4345 3305 0 11 3 36 0 sed
> [ 148.965766] [ 4346] 0 4346 3305 0 11 3 37 0 sed
> [ 148.967652] Out of memory: Kill process 4342 (resvtest) score 803 or sacrifice child
> [ 148.969390] Killed process 4342 (resvtest) total-vm:1258224kB, anon-rss:764636kB, file-rss:0kB
> [ 149.415288] XFS (vda): Unmounting Filesystem
> [ 150.211229] XFS (vda): Mounting V5 Filesystem
> [ 150.292092] XFS (vda): Ending clean mount
> [ 150.342307] XFS (vda): Unmounting Filesystem
> [ 150.346522] XFS (vdb): Unmounting Filesystem
> [ 151.264135] XFS: kmalloc allocations by trans type
> [ 151.265195] XFS: 3: count 7, bytes 3992, fails 0, max_size 1024
> [ 151.266479] XFS: 4: count 3, bytes 400, fails 0, max_size 144
> [ 151.267735] XFS: 7: count 9, bytes 2784, fails 0, max_size 536
> [ 151.269022] XFS: 16: count 1, bytes 696, fails 0, max_size 696
> [ 151.270286] XFS: 26: count 1, bytes 384, fails 0, max_size 384
> [ 151.271550] XFS: 35: count 1, bytes 696, fails 0, max_size 696
> [ 151.272833] XFS: slab allocations by trans type
> [ 151.273818] XFS: 3: count 22, bytes 0, fails 0, max_size 0
> [ 151.275010] XFS: 4: count 13, bytes 0, fails 0, max_size 0
> [ 151.276212] XFS: 7: count 12, bytes 0, fails 0, max_size 0
> [ 151.277406] XFS: 15: count 2, bytes 0, fails 0, max_size 0
> [ 151.278595] XFS: 16: count 10, bytes 0, fails 0, max_size 0
> [ 151.279854] XFS: 18: count 2, bytes 0, fails 0, max_size 0
> [ 151.281080] XFS: 26: count 3, bytes 0, fails 0, max_size 0
> [ 151.282275] XFS: 35: count 2, bytes 0, fails 0, max_size 0
> [ 151.283476] XFS: vmalloc allocations by trans type
> [ 151.284535] XFS: page allocations by trans type
>
> Those XFS allocation stats are largest measured allocations done
> under transaction context broken down by allocation and transaction
> type. No failures that would result in looping, even though the
> system invoked the OOM killer on a filesystem workload....
>
> I need to break the slab allocations down further by cache (other
> workloads are generating over 50 slab allocations per transaction),
> but another hour's work and a few days of observation of the stats
> in my normal day-to-day work wll get me all the information I need
> to do a decent first pass at memory reservation requirements for
> XFS.
>
This sounds like something that would serve us well under sysfs,
particularly if we do adopt the kind of reservation model being
discussed in this thread. I wouldn't expect these values to change
drastically or that often, but they could certainly adjust over time to
the point of being out of line with a reservation. A tool like this
combined with Johannes' idea of a warning or something along those lines
for a reservation overrun should give us all we need to identify
something is wrong and have the ability to fix it.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> --
> 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>
--
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>
next prev parent reply other threads:[~2015-03-02 12:46 UTC|newest]
Thread overview: 276+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 13:54 [RFC PATCH] oom: Don't count on mm-less current process Tetsuo Handa
2014-12-16 12:47 ` Michal Hocko
2014-12-17 11:54 ` Tetsuo Handa
2014-12-17 13:08 ` Michal Hocko
2014-12-18 12:11 ` Tetsuo Handa
2014-12-18 15:33 ` Michal Hocko
2014-12-19 12:07 ` Tetsuo Handa
2014-12-19 12:49 ` Michal Hocko
2014-12-20 9:13 ` Tetsuo Handa
2014-12-20 11:42 ` Tetsuo Handa
2014-12-22 20:25 ` Michal Hocko
2014-12-23 1:00 ` Tetsuo Handa
2014-12-23 9:51 ` Michal Hocko
2014-12-23 11:46 ` Tetsuo Handa
2014-12-23 11:57 ` Tetsuo Handa
2014-12-23 12:12 ` Tetsuo Handa
2014-12-23 12:27 ` Michal Hocko
2014-12-23 12:24 ` Michal Hocko
2014-12-23 13:00 ` Tetsuo Handa
2014-12-23 13:09 ` Michal Hocko
2014-12-23 13:20 ` Tetsuo Handa
2014-12-23 13:43 ` Michal Hocko
2014-12-23 14:11 ` Tetsuo Handa
2014-12-23 14:57 ` Michal Hocko
2014-12-19 12:22 ` How to handle TIF_MEMDIE stalls? Tetsuo Handa
2014-12-20 2:03 ` Dave Chinner
2014-12-20 12:41 ` Tetsuo Handa
2014-12-20 22:35 ` Dave Chinner
2014-12-21 8:45 ` Tetsuo Handa
2014-12-21 20:42 ` Dave Chinner
2014-12-22 16:57 ` Michal Hocko
2014-12-22 21:30 ` Dave Chinner
2014-12-23 9:41 ` Johannes Weiner
2014-12-24 1:06 ` Dave Chinner
2014-12-24 2:40 ` Linus Torvalds
2014-12-29 18:19 ` Michal Hocko
2014-12-30 6:42 ` Tetsuo Handa
2014-12-30 11:21 ` Michal Hocko
2014-12-30 13:33 ` Tetsuo Handa
2014-12-31 10:24 ` Tetsuo Handa
2015-02-09 11:44 ` Tetsuo Handa
2015-02-10 13:58 ` Tetsuo Handa
2015-02-10 15:19 ` Johannes Weiner
2015-02-11 2:23 ` Tetsuo Handa
2015-02-11 13:37 ` Tetsuo Handa
2015-02-11 18:50 ` Oleg Nesterov
2015-02-11 18:59 ` Oleg Nesterov
2015-03-14 13:03 ` Tetsuo Handa
2015-02-17 12:23 ` Tetsuo Handa
2015-02-17 12:53 ` Johannes Weiner
2015-02-17 15:38 ` Michal Hocko
2015-02-17 22:54 ` Dave Chinner
2015-02-17 22:54 ` Dave Chinner
2015-02-17 23:32 ` Dave Chinner
2015-02-17 23:32 ` Dave Chinner
2015-02-18 8:25 ` Michal Hocko
2015-02-18 8:25 ` Michal Hocko
2015-02-18 10:48 ` Dave Chinner
2015-02-18 10:48 ` Dave Chinner
2015-02-18 12:16 ` Michal Hocko
2015-02-18 12:16 ` Michal Hocko
2015-02-18 21:31 ` Dave Chinner
2015-02-18 21:31 ` Dave Chinner
2015-02-19 9:40 ` Michal Hocko
2015-02-19 9:40 ` Michal Hocko
2015-02-19 22:03 ` Dave Chinner
2015-02-19 22:03 ` Dave Chinner
2015-02-20 9:27 ` Michal Hocko
2015-02-20 9:27 ` Michal Hocko
2015-02-19 11:01 ` Johannes Weiner
2015-02-19 11:01 ` Johannes Weiner
2015-02-19 12:29 ` Michal Hocko
2015-02-19 12:29 ` Michal Hocko
2015-02-19 12:58 ` Michal Hocko
2015-02-19 12:58 ` Michal Hocko
2015-02-19 15:29 ` Tetsuo Handa
2015-02-19 15:29 ` Tetsuo Handa
2015-02-19 15:29 ` Tetsuo Handa
2015-02-19 21:53 ` Tetsuo Handa
2015-02-19 21:53 ` Tetsuo Handa
2015-02-19 21:53 ` Tetsuo Handa
2015-02-20 9:13 ` Michal Hocko
2015-02-20 9:13 ` Michal Hocko
2015-02-20 13:37 ` Stefan Ring
2015-02-20 13:37 ` Stefan Ring
2015-02-19 13:29 ` Tetsuo Handa
2015-02-19 13:29 ` Tetsuo Handa
2015-02-19 13:29 ` Tetsuo Handa
2015-02-20 9:10 ` Michal Hocko
2015-02-20 9:10 ` Michal Hocko
2015-02-20 12:20 ` Tetsuo Handa
2015-02-20 12:20 ` Tetsuo Handa
2015-02-20 12:20 ` Tetsuo Handa
2015-02-20 12:38 ` Michal Hocko
2015-02-20 12:38 ` Michal Hocko
2015-02-19 21:43 ` Dave Chinner
2015-02-19 21:43 ` Dave Chinner
2015-02-20 12:48 ` Michal Hocko
2015-02-20 12:48 ` Michal Hocko
2015-02-20 23:09 ` Dave Chinner
2015-02-20 23:09 ` Dave Chinner
2015-02-19 10:24 ` Johannes Weiner
2015-02-19 10:24 ` Johannes Weiner
2015-02-19 22:52 ` Dave Chinner
2015-02-19 22:52 ` Dave Chinner
2015-02-20 10:36 ` Tetsuo Handa
2015-02-20 10:36 ` Tetsuo Handa
2015-02-20 23:15 ` Dave Chinner
2015-02-20 23:15 ` Dave Chinner
2015-02-21 3:20 ` Theodore Ts'o
2015-02-21 3:20 ` Theodore Ts'o
2015-02-21 9:19 ` Andrew Morton
2015-02-21 9:19 ` Andrew Morton
2015-02-21 13:48 ` Tetsuo Handa
2015-02-21 13:48 ` Tetsuo Handa
2015-02-21 13:48 ` Tetsuo Handa
2015-02-21 21:38 ` Dave Chinner
2015-02-21 21:38 ` Dave Chinner
2015-02-21 21:38 ` Dave Chinner
2015-02-22 0:20 ` Johannes Weiner
2015-02-22 0:20 ` Johannes Weiner
2015-02-23 10:48 ` Michal Hocko
2015-02-23 10:48 ` Michal Hocko
2015-02-23 10:48 ` Michal Hocko
2015-02-23 11:23 ` Tetsuo Handa
2015-02-23 11:23 ` Tetsuo Handa
2015-02-23 11:23 ` Tetsuo Handa
2015-02-23 21:33 ` David Rientjes
2015-02-23 21:33 ` David Rientjes
2015-02-23 21:33 ` David Rientjes
2015-02-22 14:48 ` __GFP_NOFAIL and oom_killer_disabled? Tetsuo Handa
2015-02-23 10:21 ` Michal Hocko
2015-02-23 13:03 ` Tetsuo Handa
2015-02-24 18:14 ` Michal Hocko
2015-02-25 11:22 ` Tetsuo Handa
2015-02-25 16:02 ` Michal Hocko
2015-02-25 21:48 ` Tetsuo Handa
2015-02-25 21:51 ` Andrew Morton
2015-02-21 12:00 ` How to handle TIF_MEMDIE stalls? Tetsuo Handa
2015-02-21 12:00 ` Tetsuo Handa
2015-02-21 12:00 ` Tetsuo Handa
2015-02-23 10:26 ` Michal Hocko
2015-02-23 10:26 ` Michal Hocko
2015-02-23 10:26 ` Michal Hocko
2015-02-21 11:12 ` Tetsuo Handa
2015-02-21 11:12 ` Tetsuo Handa
2015-02-21 21:48 ` Dave Chinner
2015-02-21 21:48 ` Dave Chinner
2015-02-21 23:52 ` Johannes Weiner
2015-02-21 23:52 ` Johannes Weiner
2015-02-23 0:45 ` Dave Chinner
2015-02-23 0:45 ` Dave Chinner
2015-02-23 1:29 ` Andrew Morton
2015-02-23 1:29 ` Andrew Morton
2015-02-23 7:32 ` Dave Chinner
2015-02-23 7:32 ` Dave Chinner
2015-02-27 18:24 ` Vlastimil Babka
2015-02-27 18:24 ` Vlastimil Babka
2015-02-28 0:03 ` Dave Chinner
2015-02-28 0:03 ` Dave Chinner
2015-02-28 15:17 ` Theodore Ts'o
2015-02-28 15:17 ` Theodore Ts'o
2015-03-02 9:39 ` Vlastimil Babka
2015-03-02 9:39 ` Vlastimil Babka
2015-03-02 22:31 ` Dave Chinner
2015-03-02 22:31 ` Dave Chinner
2015-03-03 9:13 ` Vlastimil Babka
2015-03-03 9:13 ` Vlastimil Babka
2015-03-04 1:33 ` Dave Chinner
2015-03-04 1:33 ` Dave Chinner
2015-03-04 8:50 ` Vlastimil Babka
2015-03-04 8:50 ` Vlastimil Babka
2015-03-04 11:03 ` Dave Chinner
2015-03-04 11:03 ` Dave Chinner
2015-03-07 0:20 ` Johannes Weiner
2015-03-07 0:20 ` Johannes Weiner
2015-03-07 3:43 ` Dave Chinner
2015-03-07 3:43 ` Dave Chinner
2015-03-07 15:08 ` Johannes Weiner
2015-03-07 15:08 ` Johannes Weiner
2015-03-02 20:22 ` Johannes Weiner
2015-03-02 20:22 ` Johannes Weiner
2015-03-02 23:12 ` Dave Chinner
2015-03-02 23:12 ` Dave Chinner
2015-03-03 2:50 ` Johannes Weiner
2015-03-03 2:50 ` Johannes Weiner
2015-03-04 6:52 ` Dave Chinner
2015-03-04 6:52 ` Dave Chinner
2015-03-04 15:04 ` Johannes Weiner
2015-03-04 15:04 ` Johannes Weiner
2015-03-04 17:38 ` Theodore Ts'o
2015-03-04 17:38 ` Theodore Ts'o
2015-03-04 23:17 ` Dave Chinner
2015-03-04 23:17 ` Dave Chinner
2015-02-28 16:29 ` Johannes Weiner
2015-02-28 16:29 ` Johannes Weiner
2015-02-28 16:41 ` Theodore Ts'o
2015-02-28 16:41 ` Theodore Ts'o
2015-02-28 22:15 ` Johannes Weiner
2015-02-28 22:15 ` Johannes Weiner
2015-03-01 11:17 ` Tetsuo Handa
2015-03-01 11:17 ` Tetsuo Handa
2015-03-06 11:53 ` Tetsuo Handa
2015-03-06 11:53 ` Tetsuo Handa
2015-03-01 13:43 ` Theodore Ts'o
2015-03-01 13:43 ` Theodore Ts'o
2015-03-01 16:15 ` Johannes Weiner
2015-03-01 16:15 ` Johannes Weiner
2015-03-01 19:36 ` Theodore Ts'o
2015-03-01 19:36 ` Theodore Ts'o
2015-03-01 20:44 ` Johannes Weiner
2015-03-01 20:44 ` Johannes Weiner
2015-03-01 20:17 ` Johannes Weiner
2015-03-01 20:17 ` Johannes Weiner
2015-03-01 21:48 ` Dave Chinner
2015-03-01 21:48 ` Dave Chinner
2015-03-02 0:17 ` Dave Chinner
2015-03-02 0:17 ` Dave Chinner
2015-03-02 12:46 ` Brian Foster [this message]
2015-03-02 12:46 ` Brian Foster
2015-02-28 18:36 ` Vlastimil Babka
2015-02-28 18:36 ` Vlastimil Babka
2015-03-02 15:18 ` Michal Hocko
2015-03-02 15:18 ` Michal Hocko
2015-03-02 16:05 ` Johannes Weiner
2015-03-02 16:05 ` Johannes Weiner
2015-03-02 17:10 ` Michal Hocko
2015-03-02 17:10 ` Michal Hocko
2015-03-02 17:27 ` Johannes Weiner
2015-03-02 17:27 ` Johannes Weiner
2015-03-02 16:39 ` Theodore Ts'o
2015-03-02 16:39 ` Theodore Ts'o
2015-03-02 16:58 ` Michal Hocko
2015-03-02 16:58 ` Michal Hocko
2015-03-04 12:52 ` Dave Chinner
2015-03-04 12:52 ` Dave Chinner
2015-02-17 14:59 ` Michal Hocko
2015-02-17 14:50 ` Michal Hocko
2015-02-17 14:37 ` Michal Hocko
2015-02-17 14:44 ` Michal Hocko
2015-02-16 11:23 ` Tetsuo Handa
2015-02-16 15:42 ` Johannes Weiner
2015-02-17 11:57 ` Tetsuo Handa
2015-02-17 13:16 ` Johannes Weiner
2015-02-17 16:50 ` Michal Hocko
2015-02-17 23:25 ` Dave Chinner
2015-02-18 8:48 ` Michal Hocko
2015-02-18 11:23 ` Tetsuo Handa
2015-02-18 11:23 ` Tetsuo Handa
2015-02-18 12:29 ` Michal Hocko
2015-02-18 12:29 ` Michal Hocko
2015-02-18 14:06 ` Tetsuo Handa
2015-02-18 14:06 ` Tetsuo Handa
2015-02-18 14:25 ` Michal Hocko
2015-02-19 10:48 ` Tetsuo Handa
2015-02-19 10:48 ` Tetsuo Handa
2015-02-20 8:26 ` Michal Hocko
2015-02-20 8:26 ` Michal Hocko
2015-02-23 22:08 ` David Rientjes
2015-02-24 11:20 ` Tetsuo Handa
2015-02-24 15:20 ` Theodore Ts'o
2015-02-24 21:02 ` Dave Chinner
2015-02-25 14:31 ` Tetsuo Handa
2015-02-27 7:39 ` Dave Chinner
2015-02-27 12:42 ` Tetsuo Handa
2015-02-27 13:12 ` Dave Chinner
2015-03-04 12:41 ` Tetsuo Handa
2015-03-04 13:25 ` Dave Chinner
2015-03-04 14:11 ` Tetsuo Handa
2015-03-05 1:36 ` Dave Chinner
2015-02-17 16:33 ` Michal Hocko
2014-12-29 17:40 ` [PATCH] mm: get rid of radix tree gfp mask for pagecache_get_page (was: Re: How to handle TIF_MEMDIE stalls?) Michal Hocko
2014-12-29 18:45 ` Linus Torvalds
2014-12-29 19:33 ` Michal Hocko
2014-12-30 13:42 ` Michal Hocko
2014-12-30 21:45 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302124626.GA25593@laptop.bfoster \
--to=bfoster@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=oleg@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.