* [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations @ 2015-09-20 7:03 Tetsuo Handa 2015-09-20 7:03 ` [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Tetsuo Handa 2015-09-20 23:11 ` [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Dave Chinner 0 siblings, 2 replies; 8+ messages in thread From: Tetsuo Handa @ 2015-09-20 7:03 UTC (permalink / raw) To: david; +Cc: xfs, linux-mm, Tetsuo Handa, Michal Hocko kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing open-coded __GFP_NOFAIL allocations with warning messages as a canary. But since small !__GFP_NOFAIL allocations retry forever inside memory allocator unless TIF_MEMDIE is set, the canary does not help even if allocations are stalling. Thus, this patch adds __GFP_NORETRY so that we can know possibility of allocation deadlock. If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not retry inside memory allocator is merged, warning messages by warn_alloc_failed() will dominate warning messages by the canary because each thread calls warn_alloc_failed() for approximately every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. Next patch compensates for lack of comm name and pid by addding them to the canary. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Michal Hocko <mhocko@suse.com> --- fs/xfs/kmem.c | 4 ++-- fs/xfs/xfs_buf.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..1fcf90d 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -46,7 +46,7 @@ void * kmem_alloc(size_t size, xfs_km_flags_t flags) { int retries = 0; - gfp_t lflags = kmem_flags_convert(flags); + gfp_t lflags = kmem_flags_convert(flags) | __GFP_NORETRY | __GFP_NOWARN; void *ptr; do { @@ -111,7 +111,7 @@ void * kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) { int retries = 0; - gfp_t lflags = kmem_flags_convert(flags); + gfp_t lflags = kmem_flags_convert(flags) | __GFP_NORETRY | __GFP_NOWARN; void *ptr; do { diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..cbd4f91 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -289,7 +289,7 @@ xfs_buf_allocate_memory( { size_t size; size_t nbytes, offset; - gfp_t gfp_mask = xb_to_gfp(flags); + gfp_t gfp_mask = xb_to_gfp(flags) | __GFP_NORETRY | __GFP_NOWARN; unsigned short page_count, i; xfs_off_t start, end; int error; -- 1.8.3.1 -- 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 related [flat|nested] 8+ messages in thread
* [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks 2015-09-20 7:03 [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Tetsuo Handa @ 2015-09-20 7:03 ` Tetsuo Handa 2015-09-20 23:18 ` Dave Chinner 2015-09-20 23:11 ` [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Dave Chinner 1 sibling, 1 reply; 8+ messages in thread From: Tetsuo Handa @ 2015-09-20 7:03 UTC (permalink / raw) To: david; +Cc: xfs, linux-mm, Tetsuo Handa, Michal Hocko This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling. [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Michal Hocko <mhocko@suse.com> --- fs/xfs/kmem.c | 6 ++++-- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index 1fcf90d..95a5b76 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -54,8 +54,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); @@ -119,8 +120,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index cbd4f91..5deb629 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -353,8 +353,9 @@ retry: * handle buffer allocation failures we can't do much. */ if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 -- 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 related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks 2015-09-20 7:03 ` [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Tetsuo Handa @ 2015-09-20 23:18 ` Dave Chinner 2015-09-21 1:23 ` [PATCH v2] " Tetsuo Handa 0 siblings, 1 reply; 8+ messages in thread From: Dave Chinner @ 2015-09-20 23:18 UTC (permalink / raw) To: Tetsuo Handa; +Cc: xfs, linux-mm, Michal Hocko On Sun, Sep 20, 2015 at 04:03:14PM +0900, Tetsuo Handa wrote: > This patch adds comm name and pid to warning messages printed by > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). > This will help telling which memory allocations (e.g. kernel worker > threads, OOM victim tasks, neither) are stalling. > > [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child > [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB > [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > > (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > Cc: Michal Hocko <mhocko@suse.com> > --- > fs/xfs/kmem.c | 6 ++++-- > fs/xfs/xfs_buf.c | 3 ++- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c > index 1fcf90d..95a5b76 100644 > --- a/fs/xfs/kmem.c > +++ b/fs/xfs/kmem.c > @@ -54,8 +54,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) > if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) > return ptr; > if (!(++retries % 100)) > - xfs_err(NULL, > + xfs_err(NULL, "%s(%u) " > "possible memory allocation deadlock in %s (mode:0x%x)", > + current->comm, current->pid, > __func__, lflags); The format string will fit on a single line: "%s(%u): Possible memory allocation deadlock in %s (mode:0x%x)", 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks 2015-09-20 23:18 ` Dave Chinner @ 2015-09-21 1:23 ` Tetsuo Handa 2015-09-22 5:12 ` Dave Chinner 0 siblings, 1 reply; 8+ messages in thread From: Tetsuo Handa @ 2015-09-21 1:23 UTC (permalink / raw) To: david; +Cc: xfs, linux-mm, Tetsuo Handa, Michal Hocko This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling because these functions are passing __GFP_NOWARN which suppresses not only backtrace but comm name and pid. [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Michal Hocko <mhocko@suse.com> --- fs/xfs/kmem.c | 10 ++++++---- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..735095a 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } @@ -120,8 +121,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..86785b5 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -354,7 +354,8 @@ retry: */ if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 -- 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 related [flat|nested] 8+ messages in thread
* Re: [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks 2015-09-21 1:23 ` [PATCH v2] " Tetsuo Handa @ 2015-09-22 5:12 ` Dave Chinner 2015-09-22 8:03 ` [PATCH v3] " Tetsuo Handa 0 siblings, 1 reply; 8+ messages in thread From: Dave Chinner @ 2015-09-22 5:12 UTC (permalink / raw) To: Tetsuo Handa; +Cc: xfs, linux-mm, Michal Hocko On Mon, Sep 21, 2015 at 10:23:57AM +0900, Tetsuo Handa wrote: > This patch adds comm name and pid to warning messages printed by > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). > This will help telling which memory allocations (e.g. kernel worker > threads, OOM victim tasks, neither) are stalling because these functions > are passing __GFP_NOWARN which suppresses not only backtrace but comm name > and pid. > > [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child > [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB > [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > > (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > Cc: Michal Hocko <mhocko@suse.com> > --- > fs/xfs/kmem.c | 10 ++++++---- > fs/xfs/xfs_buf.c | 3 ++- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c > index a7a3a63..735095a 100644 > --- a/fs/xfs/kmem.c > +++ b/fs/xfs/kmem.c > @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) > return ptr; > if (!(++retries % 100)) > xfs_err(NULL, > - "possible memory allocation deadlock in %s (mode:0x%x)", > - __func__, lflags); > + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", > + current->comm, current->pid, > + __func__, lflags); <=80 columns, please. 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks 2015-09-22 5:12 ` Dave Chinner @ 2015-09-22 8:03 ` Tetsuo Handa 0 siblings, 0 replies; 8+ messages in thread From: Tetsuo Handa @ 2015-09-22 8:03 UTC (permalink / raw) To: david; +Cc: xfs, linux-mm, Tetsuo Handa, Michal Hocko This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling because these functions are passing __GFP_NOWARN which suppresses not only backtrace but comm name and pid. [ 66.089978] Kill process 8505 (a.out) sharing same memory [ 69.748060] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.798580] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.876952] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 70.359518] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.299509] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.470350] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 73.664420] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.967434] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.950038] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.957938] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Michal Hocko <mhocko@suse.com> --- fs/xfs/kmem.c | 10 ++++++---- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..535c136 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } @@ -120,8 +121,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..cac62e1 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -354,7 +354,8 @@ retry: */ if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 -- 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 related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations 2015-09-20 7:03 [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Tetsuo Handa 2015-09-20 7:03 ` [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Tetsuo Handa @ 2015-09-20 23:11 ` Dave Chinner 2015-09-21 1:23 ` Tetsuo Handa 1 sibling, 1 reply; 8+ messages in thread From: Dave Chinner @ 2015-09-20 23:11 UTC (permalink / raw) To: Tetsuo Handa; +Cc: xfs, linux-mm, Michal Hocko On Sun, Sep 20, 2015 at 04:03:13PM +0900, Tetsuo Handa wrote: > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing > open-coded __GFP_NOFAIL allocations with warning messages as a canary. > But since small !__GFP_NOFAIL allocations retry forever inside memory > allocator unless TIF_MEMDIE is set, the canary does not help even if > allocations are stalling. Thus, this patch adds __GFP_NORETRY so that > we can know possibility of allocation deadlock. > > If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not > retry inside memory allocator is merged, warning messages by > warn_alloc_failed() will dominate warning messages by the canary > because each thread calls warn_alloc_failed() for approximately > every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that > we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. Please, at minimum, look at the code you are modifying. __GFP_NOWARN is already set by both kmem_flags_convert() and xb_to_gfp(), precisely for this reason. Any changes to the default gfp flags we use need to be inside those wrappers - that's why they exist. Further, xb_to_gfp() may already return just "__GFP_NORETRY | __GFP_NOWARN", so appending them unconditionally is clearly not the best approach. Further, fundamentally changing the allocation behaviour of the filesystem requires some indication of the testing and characterisation of how the change has impacted low memory balance and performance of the filesystem. 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations 2015-09-20 23:11 ` [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Dave Chinner @ 2015-09-21 1:23 ` Tetsuo Handa 0 siblings, 0 replies; 8+ messages in thread From: Tetsuo Handa @ 2015-09-21 1:23 UTC (permalink / raw) To: david; +Cc: xfs, linux-mm, mhocko Dave Chinner wrote: > On Sun, Sep 20, 2015 at 04:03:13PM +0900, Tetsuo Handa wrote: > > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing > > open-coded __GFP_NOFAIL allocations with warning messages as a canary. > > But since small !__GFP_NOFAIL allocations retry forever inside memory > > allocator unless TIF_MEMDIE is set, the canary does not help even if > > allocations are stalling. Thus, this patch adds __GFP_NORETRY so that > > we can know possibility of allocation deadlock. > > > > If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not > > retry inside memory allocator is merged, warning messages by > > warn_alloc_failed() will dominate warning messages by the canary > > because each thread calls warn_alloc_failed() for approximately > > every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that > > we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. > > Please, at minimum, look at the code you are modifying. __GFP_NOWARN > is already set by both kmem_flags_convert() and xb_to_gfp(), > precisely for this reason. Any changes to the default gfp flags we > use need to be inside those wrappers - that's why they exist. Indeed. > > Further, xb_to_gfp() may already return just "__GFP_NORETRY | > __GFP_NOWARN", so appending them unconditionally is clearly not the > best approach. I see. > > Further, fundamentally changing the allocation behaviour of the > filesystem requires some indication of the testing and > characterisation of how the change has impacted low memory balance > and performance of the filesystem. Well, I don't have rich environment for evaluating how the change impacts low memory balance and performance of the filesystem. Therefore, I cancel this patch. Please reply if you have comments on "[RFC 0/8] Allow GFP_NOFS allocation to fail" patchset ( http://marc.info/?l=linux-mm&m=143876830616538 )? -- 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] 8+ messages in thread
end of thread, other threads:[~2015-09-22 8:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-20 7:03 [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Tetsuo Handa 2015-09-20 7:03 ` [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Tetsuo Handa 2015-09-20 23:18 ` Dave Chinner 2015-09-21 1:23 ` [PATCH v2] " Tetsuo Handa 2015-09-22 5:12 ` Dave Chinner 2015-09-22 8:03 ` [PATCH v3] " Tetsuo Handa 2015-09-20 23:11 ` [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Dave Chinner 2015-09-21 1:23 ` Tetsuo Handa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).