* [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 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 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
* 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
* [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
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).