[patch] mm, slab: show total unreclaimable slab footprint on oom

[patch] mm, slab: show total unreclaimable slab footprint on oom

[David Rientjes]

When there is a large amount of unreclaimable slab memory in use at the
time of oom kill, what really matters is the memory footprint that it
consumes rather than only the number of active and total objects.

Include the memory footprint in the kernel log for debugging.

This may overestimate the amount of memory since slab pages may not be
all of the same order, but it gives a useful upper bound for
understanding where all the memory is going similar to slabinfo.

At the same time, align the fields for some lengthy slab cache names such
as fsnotify_mark_connector.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/slab_common.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1145,7 +1145,7 @@ void dump_unreclaimable_slab(void)
 	}
 
 	pr_info("Unreclaimable slab info:\n");
-	pr_info("Name                      Used          Total\n");
+	pr_info("Name                            Active_objs   Total_objs       Memory\n");
 
 	list_for_each_entry(s, &slab_caches, list) {
 		if (s->flags & SLAB_RECLAIM_ACCOUNT)
@@ -1154,9 +1154,10 @@ void dump_unreclaimable_slab(void)
 		get_slabinfo(s, &sinfo);
 
 		if (sinfo.num_objs > 0)
-			pr_info("%-17s %10luKB %10luKB\n", s->name,
-				(sinfo.active_objs * s->size) / 1024,
-				(sinfo.num_objs * s->size) / 1024);
+			pr_info("%-30s %10luKB %10luKB %10luKB\n", s->name,
+				(sinfo.active_objs * s->size) >> 10,
+				(sinfo.num_objs * s->size) >> 10,
+				sinfo.num_slabs << (sinfo.cache_order + PAGE_SHIFT - 10));
 	}
 	mutex_unlock(&slab_mutex);
 }

Re: [patch] mm, slab: show total unreclaimable slab footprint on oom

[Harry Yoo]

On Sat, Apr 19, 2025 at 07:26:11PM -0700, David Rientjes wrote:
> When there is a large amount of unreclaimable slab memory in use at the
> time of oom kill, what really matters is the memory footprint that it
> consumes rather than only the number of active and total objects.
>
> Include the memory footprint in the kernel log for debugging.
>
> This may overestimate the amount of memory since slab pages may not be
> all of the same order, but it gives a useful upper bound for
> understanding where all the memory is going similar to slabinfo.
>
> At the same time, align the fields for some lengthy slab cache names such
> as fsnotify_mark_connector.
> 
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---

Reviewed-by: Harry Yoo <harry.yoo@oracle.com>

By the way would it overkill to maintain a slab usage counter per
kmem_cache_node (Yes. one more atomic in allocate_slab()/discard_slab())
Or it doesn't need to be that accurate?

-- 
Cheers,
Harry / Hyeonggon

>  mm/slab_common.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1145,7 +1145,7 @@ void dump_unreclaimable_slab(void)
>  	}
>  
>  	pr_info("Unreclaimable slab info:\n");
> -	pr_info("Name                      Used          Total\n");
> +	pr_info("Name                            Active_objs   Total_objs       Memory\n");
>  
>  	list_for_each_entry(s, &slab_caches, list) {
>  		if (s->flags & SLAB_RECLAIM_ACCOUNT)
> @@ -1154,9 +1154,10 @@ void dump_unreclaimable_slab(void)
>  		get_slabinfo(s, &sinfo);
>  
>  		if (sinfo.num_objs > 0)
> -			pr_info("%-17s %10luKB %10luKB\n", s->name,
> -				(sinfo.active_objs * s->size) / 1024,
> -				(sinfo.num_objs * s->size) / 1024);
> +			pr_info("%-30s %10luKB %10luKB %10luKB\n", s->name,
> +				(sinfo.active_objs * s->size) >> 10,
> +				(sinfo.num_objs * s->size) >> 10,
> +				sinfo.num_slabs << (sinfo.cache_order + PAGE_SHIFT - 10));
>  	}
>  	mutex_unlock(&slab_mutex);
>  }