All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm, slab: show total unreclaimable slab footprint on oom
Date: Mon, 21 Apr 2025 18:17:15 +0900	[thread overview]
Message-ID: <aAYNG_Fp18Pn4_TD@harry> (raw)
In-Reply-To: <93c5936a-fbcf-20a5-af1d-bee840e18d39@google.com>

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


      reply	other threads:[~2025-04-21  9:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-20  2:26 [patch] mm, slab: show total unreclaimable slab footprint on oom David Rientjes
2025-04-21  9:17 ` Harry Yoo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAYNG_Fp18Pn4_TD@harry \
    --to=harry.yoo@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.