mm, slab: show total unreclaimable slab footprint on oom

Commit Message

David Rientjes April 20, 2025, 2:26 a.m. UTC

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 <[e-mail]>
---
 mm/slab_common.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Patch

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);
 }