All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Usama Arif <usamaarif642@gmail.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>,
	surenb@google.com, Andrew Morton <akpm@linux-foundation.org>,
	hannes@cmpxchg.org, vlad.wing@gmail.com, linux-mm@kvack.org,
	kent.overstreet@linux.dev, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, vbabka@suse.cz, cl@gentwo.org,
	rientjes@google.com, roman.gushchin@linux.dev
Subject: Re: [PATCH 2/2] mm: slub: only warn once when allocating slab obj extensions fails
Date: Thu, 22 May 2025 09:16:16 +0900	[thread overview]
Message-ID: <aC5s0CQMHeud3LDa@hyeyoo> (raw)
In-Reply-To: <64b19c8f-e02e-490b-b987-9a996f36be21@gmail.com>

On Tue, May 20, 2025 at 04:22:16PM +0100, Usama Arif wrote:
> 
> 
> On 20/05/2025 15:18, Shakeel Butt wrote:
> > On Tue, May 20, 2025 at 02:42:09PM +0100, Usama Arif wrote:
> >>
> >>
> >> On 20/05/2025 14:34, Harry Yoo wrote:
> >>> On Tue, May 20, 2025 at 01:25:47PM +0100, Usama Arif wrote:
> >>>> In memory bound systems, a large number of warnings for failing this
> >>>> allocation repeatedly may mask any real issues in the system
> >>>> during memory pressure being reported in dmesg. Change this to
> >>>> WARN_ONCE.
> >>>>
> >>>> Signed-off-by: Usama Arif <usamaarif642@gmail.com>
> >>>> Reported-by: Vlad Poenaru <vlad.wing@gmail.com>
> >>>> Closes: https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/
> >>>> ---
> >>>
> >>> Hi,
> >>>
> >>> Please Cc SLAB ALLOCATOR folks in MAINTAINERS on patches that touch
> >>> slab code ;)
> >>>
> >>
> >> Thanks for adding them to CC! I was just thinking of this as a memory
> >> allocation profiling issue and added the maintainers for it,
> >> but should have added slab maintainers as well.
> >>
> >>
> >>>>  mm/slub.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/mm/slub.c b/mm/slub.c
> >>>> index bf43c403ead2..97cb3d9e8d00 100644
> >>>> --- a/mm/slub.c
> >>>> +++ b/mm/slub.c
> >>>> @@ -2102,7 +2102,7 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> >>>>  
> >>>>  	slab = virt_to_slab(p);
> >>>>  	if (!slab_obj_exts(slab) &&
> >>>> -	    WARN(alloc_slab_obj_exts(slab, s, flags, false),
> >>>> +	    WARN_ONCE(alloc_slab_obj_exts(slab, s, flags, false),
> >>>>  		 "%s, %s: Failed to create slab extension vector!\n",
> >>>>  		 __func__, s->name))
> >>>
> >>> I think this should be pr_warn_once()?
> >>> I'm not sure why this was WARN() in the first place.
> >>>
> >>
> >> Isn't WARN_ONCE the same as pr_warn_once but with needing the condition
> >> of the first arg to be true? We only want to warn if alloc_slab_obj_exts
> >> returns non-zero. So WARN_ONCE should be ok?
> >>
> > 
> > The difference is the impact on panic_on_warn users which are mostly
> > testing bots. This warning is not actionable, so I agree with Harry to
> > covert this to pr_warn_once().
> > 
> 
> Sounds good! Will change it to below for the next revision.
> Will wait for the kvmalloc conversation to conclude before sending
> the next revision.
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 08804d2f2ead..ab0b7ee87159 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2101,11 +2101,13 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
>                 return NULL;
>  
>         slab = virt_to_slab(p);
> -       if (!slab_obj_exts(slab) &&
> -           WARN(alloc_slab_obj_exts(slab, s, flags, false),
> -                "%s, %s: Failed to create slab extension vector!\n",
> -                __func__, s->name))
> -               return NULL;
> +       if (!slab_obj_exts(slab)) {
> +               if(alloc_slab_obj_exts(slab, s, flags, false))
> +                       pr_warn_once("%s, %s: Failed to create slab extension vector!\n",
> +                               __func__, s->name);
> +               else
> +                       return NULL;

Returning NULL when alloc_slab_obj_exts() succeeds doesn't make sense.
I think you meant something like this?

if (!slab_obj_exts(slab) &&
    alloc_slab_obj_exts(slab, s, flags, false)) {
	pr_warn_once("%s, %s: Failed to create slab extension vector!\n",
		__func__, s->name);
	return NULL;
}

> +       }
>  
>         return slab_obj_exts(slab) + obj_to_index(s, slab, p);
>  }
> 

-- 
Cheers,
Harry / Hyeonggon


  reply	other threads:[~2025-05-22  0:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20 12:25 [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously Usama Arif
2025-05-20 12:25 ` [PATCH 2/2] mm: slub: only warn once when allocating slab obj extensions fails Usama Arif
2025-05-20 13:34   ` Harry Yoo
2025-05-20 13:42     ` Usama Arif
2025-05-20 14:18       ` Shakeel Butt
2025-05-20 15:14         ` Suren Baghdasaryan
2025-05-20 15:22         ` Usama Arif
2025-05-22  0:16           ` Harry Yoo [this message]
2025-05-22 12:42             ` Usama Arif
2025-05-20 13:44 ` [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously Kent Overstreet
2025-05-20 13:46   ` Usama Arif
2025-05-20 14:01     ` Kent Overstreet
2025-05-20 14:24       ` Shakeel Butt
2025-05-20 14:28         ` Kent Overstreet
2025-05-20 17:44           ` Uladzislau Rezki
2025-05-20 17:47             ` Kent Overstreet
2025-05-20 17:57               ` Uladzislau Rezki
2025-05-20 17:58                 ` Kent Overstreet
2025-05-20 18:59                   ` Uladzislau Rezki
2025-05-20 14:13     ` Usama Arif
2025-05-20 15:20       ` Suren Baghdasaryan
2025-05-20 16:41         ` Kent Overstreet
2025-05-20 17:20           ` Suren Baghdasaryan
2025-05-20 17:25             ` Kent Overstreet
2025-05-20 17:18         ` Johannes Weiner
2025-05-20 14:01 ` Usama Arif

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=aC5s0CQMHeud3LDa@hyeyoo \
    --to=harry.yoo@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=hannes@cmpxchg.org \
    --cc=kent.overstreet@linux.dev \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=vlad.wing@gmail.com \
    /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.