mm: SLAB Out-of-memory diagnostics
Subsystems (4)
PATCH 1/1 mm: SLAB Out-of-memory diagnostics
Following the example at mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of __GFP_NOWARN page allocation flag and forces the kernel to report every slab allocation failure.
An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
cache: bio-0, object size: 192, order: 0
node0: slabs: 3/3, objs: 60/60, free: 0--- Documentation/sysctl/vm.txt | 23 ++++++++++++++++++ include/linux/slab.h | 2 + kernel/sysctl.c | 9 +++++++ mm/slab.c | 55 ++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 88 insertions(+), 1 deletions(-)
Documentation/sysctl/vm.txt +23 -0
@@ -498,6 +498,29 @@ this is causing problems for your system/application. ============================================================== +oom_dump_slabs_forced + +Overrides the effects of __GFP_NOWARN page allocation flag, thus forcing +the system to print warnings about every allocation failure for the +slab allocator, and helping on debugging certain OOM conditions. +The print out is pretty similar, and complements data that is reported by +the page allocator out-of-memory warning: + +<snip page allocator out-of-memory message> + SLAB: Unable to allocate memory on node 0 (gfp=0x11200) + cache: bio-0, object size: 192, order: 0 + node0: slabs: 3/3, objs: 60/60, free: 0 + +If this is set to zero, the default behavior is observed and warnings will only +be printed out for allocation requests that didn't set the __GFP_NOWARN flag. + +When set to non-zero, this information is shown whenever the allocator finds +itself failing to grant a request, regardless the __GFP_NOWARN flag status. + +The default value is 0 (disabled). + +============================================================== + oom_dump_tasks Enables a system-wide task dump (excluding kernel threads) to be
include/linux/slab.h +2 -0
@@ -353,4 +353,6 @@ static inline void *kzalloc_node(size_t size, gfp_t flags, int node)void __init kmem_cache_init_late (void ); +/* sysctl */ +extern int sysctl_oom_dump_slabs;#endif /* _LINUX_SLAB_H */
kernel/sysctl.c +9 -0
@@ -1040,6 +1040,15 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_dointvec, }, +#if defined(CONFIG_SLAB) + { + .procname = "oom_dump_slabs_forced", + .data = &sysctl_oom_dump_slabs, + .maxlen = sizeof(sysctl_oom_dump_slabs), + .mode = 0644, + .proc_handler = proc_dointvec, + }, +#endif { .procname = "overcommit_ratio", .data = &sysctl_overcommit_ratio,
mm/slab.c +54 -1
74 lines not on this page · raw message
Signature · 8 lines
1.7.7.6 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 12 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0
Quoted 7 lines
Signed-off-by Rafael Aquini <[email protected]>--- Documentation/sysctl/vm.txt | 23 ++++++++++++++++++ include/linux/slab.h | 2 + kernel/sysctl.c | 9 +++++++ mm/slab.c | 55 ++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 88 insertions(+), 1 deletions(-)
No SLUB support for this?
Quoted 21 lines
Documentation/sysctl/vm.txt +13
-0@@ -498,6 +498,29 @@ this is causing problems for your system/application. ============================================================== +oom_dump_slabs_forced + +Overrides the effects of __GFP_NOWARN page allocation flag, thus forcing +the system to print warnings about every allocation failure for the +slab allocator, and helping on debugging certain OOM conditions. +The print out is pretty similar, and complements data that is reported by +the page allocator out-of-memory warning: + +<snip page allocator out-of-memory message> + SLAB: Unable to allocate memory on node 0 (gfp=0x11200) + cache: bio-0, object size: 192, order: 0 + node0: slabs: 3/3, objs: 60/60, free: 0 +
Documentation/sysctl/vm.txt this is causing problems for your system/application. · line 523
Quoted 10 lines
Documentation/sysctl/vm.txt +10
-0+If this is set to zero, the default behavior is observed and warnings will only +be printed out for allocation requests that didn't set the __GFP_NOWARN flag. + +When set to non-zero, this information is shown whenever the allocator finds +itself failing to grant a request, regardless the __GFP_NOWARN flag status. + +The default value is 0 (disabled). + +============================================================== +
Why do you want to add a sysctl for this? That'd be an ABI that we need to keep around forever.
Is there any reason we shouldn't just enable this unconditionally?
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 21 lines · Pekka Enberg
Quoted 12 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0Quoted 7 lines
Signed-off-by Rafael Aquini <[email protected]>--- Documentation/sysctl/vm.txt | 23 ++++++++++++++++++ include/linux/slab.h | 2 + kernel/sysctl.c | 9 +++++++ mm/slab.c | 55 ++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 88 insertions(+), 1 deletions(-)
Quoted 1 line
No SLUB support for this?
SLUB already has its version of slab_out_of_memory. I did not propose the sysctl knob for slub, however. (If we find the knob useful, I can propose its extention to slub, later).
Quoted 36 lines
Quoted 22 lines
Documentation/sysctl/vm.txt +13
-0@@ -498,6 +498,29 @@ this is causing problems for your system/application. ============================================================== +oom_dump_slabs_forced + +Overrides the effects of __GFP_NOWARN page allocation flag, thus forcing +the system to print warnings about every allocation failure for the +slab allocator, and helping on debugging certain OOM conditions. +The print out is pretty similar, and complements data that is reported by +the page allocator out-of-memory warning: + +<snip page allocator out-of-memory message> + SLAB: Unable to allocate memory on node 0 (gfp=0x11200) + cache: bio-0, object size: 192, order: 0 + node0: slabs: 3/3, objs: 60/60, free: 0 +Documentation/sysctl/vm.txt this is causing problems for your system/application. · line 523
Quoted 10 lines
Documentation/sysctl/vm.txt +10
-0+If this is set to zero, the default behavior is observed and warnings will only +be printed out for allocation requests that didn't set the __GFP_NOWARN flag. + +When set to non-zero, this information is shown whenever the allocator finds +itself failing to grant a request, regardless the __GFP_NOWARN flag status. + +The default value is 0 (disabled). + +============================================================== +Why do you want to add a sysctl for this? That'd be an ABI that we need to keep around forever.
Quoted 1 line
Is there any reason we shouldn't just enable this unconditionally?
I was afraid of this code becoming a source of garrulous and scaring warnings by just ignoring __GFP_NOWARN flag, however, I was also concerned with the 'hiding' effect the flag imposes for certain requests, specially when one is interested in checking all those requests out. Therefore, I thought a sysctl knob would be the best option to control the __GFP_NOWARN overriding behavior of slab_out_of_memory printouts without messing with the allocation flags themselves, as well as not imposing the need for reboots to start checking all slab allocation failures out.
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 21 lines · Pekka Enberg
Quoted 12 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0Quoted 7 lines
Signed-off-by Rafael Aquini <[email protected]>--- Documentation/sysctl/vm.txt | 23 ++++++++++++++++++ include/linux/slab.h | 2 + kernel/sysctl.c | 9 +++++++ mm/slab.c | 55 ++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 88 insertions(+), 1 deletions(-)
Quoted 2 lines
No SLUB support for this?
SLUB already has its version of slab_out_of_memory. I did not propose the sysctl knob for slub, however. (If we find the knob useful, I can propose its extention to slub, later).
Quoted 35 lines
Quoted 21 lines
Documentation/sysctl/vm.txt +13
-0@@ -498,6 +498,29 @@ this is causing problems for your system/application. ============================================================== +oom_dump_slabs_forced + +Overrides the effects of __GFP_NOWARN page allocation flag, thus forcing +the system to print warnings about every allocation failure for the +slab allocator, and helping on debugging certain OOM conditions. +The print out is pretty similar, and complements data that is reported by +the page allocator out-of-memory warning: + +<snip page allocator out-of-memory message> + SLAB: Unable to allocate memory on node 0 (gfp=0x11200) + cache: bio-0, object size: 192, order: 0 + node0: slabs: 3/3, objs: 60/60, free: 0 +Documentation/sysctl/vm.txt this is causing problems for your system/application. · line 523
Quoted 10 lines
Documentation/sysctl/vm.txt +10
-0+If this is set to zero, the default behavior is observed and warnings will only +be printed out for allocation requests that didn't set the __GFP_NOWARN flag. + +When set to non-zero, this information is shown whenever the allocator finds +itself failing to grant a request, regardless the __GFP_NOWARN flag status. + +The default value is 0 (disabled). + +============================================================== +Why do you want to add a sysctl for this? That'd be an ABI that we need to keep around forever.
Quoted 1 line
Is there any reason we shouldn't just enable this unconditionally?
I was afraid of this code becoming a source of garrulous and scaring warnings by just ignoring __GFP_NOWARN flag, however, I was also concerned with the 'hiding' effect the flag imposes for certain requests, specially when one is interested in checking all those requests out. Therefore, I thought a sysctl knob would be the best option to control the __GFP_NOWARN overriding behavior of slab_out_of_memory printouts without messing with the allocation flags themselves, as well as not imposing the need for reboots to start checking all slab allocation failures out.
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
David Rientjes
reviewerQuoted 5 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.
Quoted 8 lines
An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0Signed-off-by Rafael Aquini <[email protected]>
I like it, except for the addition of the sysctl. __GFP_NOWARN is used for a reason, usually because whatever is allocating memory can gracefully handle a failure and should not be emitted to the kernel log under any circumstances.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 14 lines · David Rientjes
Quoted 12 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0
Quoted 6 lines
Quoted 1 line
Signed-off-by Rafael Aquini <[email protected]>I like it, except for the addition of the sysctl.
__GFP_NOWARNis used for a reason, usually because whatever is allocating memory can gracefully handle a failure and should not be emitted to the kernel log under any circumstances.
Ok, I'll drop the sysctl part then. Pekka?
David, once again, thanks for your feedback!
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 15 lines · Rafael Aquini
Quoted 14 lines · David Rientjes
Quoted 12 lines · Rafael Aquini
Following the example at
mm/slub.c, add out-of-memory diagnostics to the SLAB allocator to help on debugging OOM conditions. This patch also adds a new sysctl, 'oom_dump_slabs_forced', that overrides the effect of__GFP_NOWARNpage allocation flag and forces the kernel to report every slab allocation failure.An example print out looks like this:
<snip page allocator out-of-memory message>
SLAB: Unable to allocate memory on node 0 (gfp=0x11200)cache: bio-0, object size: 192, order: 0 node0: slabs: 3/3, objs: 60/60, free: 0
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Rafael Aquini <[email protected]>I like it, except for the addition of the sysctl.
__GFP_NOWARNis used for a reason, usually because whatever is allocating memory can gracefully handle a failure and should not be emitted to the kernel log under any circumstances.Ok, I'll drop the sysctl part then. Pekka?
Yes, please.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>