1. Patchew
  2. linux
  3. View series

[PATCH] mm: slub: do not warn when allocating slab obj extensions fails

Usama Arif posted 1 patch 6 months, 3 weeks ago 
mm/slub.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
[PATCH] mm: slub: do not warn when allocating slab obj extensions fails
Posted by Usama Arif 6 months, 3 weeks ago 
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. Failing this
allocation is not indicative of a bug, so remove the warning.

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/
---
v1 -> v2:
- remove the warning completely. We will have a way in the
  future to indicate that the mem alloc profile is inaccurate.
---
 mm/slub.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index dc9e729e1d26..06ab9a558b73 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2102,9 +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),
-		 "%s, %s: Failed to create slab extension vector!\n",
-		 __func__, s->name))
+	    alloc_slab_obj_exts(slab, s, flags, false))
 		return NULL;
 
 	return slab_obj_exts(slab) + obj_to_index(s, slab, p);
-- 
2.47.1
Re: [PATCH] mm: slub: do not warn when allocating slab obj extensions fails
Posted by Suren Baghdasaryan 6 months, 3 weeks ago 
On Wed, May 21, 2025 at 7:25 AM Usama Arif <usamaarif642@gmail.com> 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. Failing this
> allocation is not indicative of a bug, so remove the warning.
>
> 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/
> ---
> v1 -> v2:
> - remove the warning completely. We will have a way in the
>   future to indicate that the mem alloc profile is inaccurate.
> ---
>  mm/slub.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index dc9e729e1d26..06ab9a558b73 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2102,9 +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),
> -                "%s, %s: Failed to create slab extension vector!\n",
> -                __func__, s->name))
> +           alloc_slab_obj_exts(slab, s, flags, false))

I thought we agreed to having pr_warn_once() here. Did I miss something?

>                 return NULL;
>
>         return slab_obj_exts(slab) + obj_to_index(s, slab, p);
> --
> 2.47.1
>
Re: [PATCH] mm: slub: do not warn when allocating slab obj extensions fails
Posted by Usama Arif 6 months, 3 weeks ago 

On 21/05/2025 17:02, Suren Baghdasaryan wrote:
> On Wed, May 21, 2025 at 7:25 AM Usama Arif <usamaarif642@gmail.com> 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. Failing this
>> allocation is not indicative of a bug, so remove the warning.
>>
>> 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/
>> ---
>> v1 -> v2:
>> - remove the warning completely. We will have a way in the
>>   future to indicate that the mem alloc profile is inaccurate.
>> ---
>>  mm/slub.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index dc9e729e1d26..06ab9a558b73 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2102,9 +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),
>> -                "%s, %s: Failed to create slab extension vector!\n",
>> -                __func__, s->name))
>> +           alloc_slab_obj_exts(slab, s, flags, false))
> 
> I thought we agreed to having pr_warn_once() here. Did I miss something?
> 

I had [1] yesterday but I saw Johannes's mail [2] in and Harry mentioned in [3] that
failing to allocate the extension vector can happen during normal operations. So I
thought maybe there are more votes for removing it.

I am ok with either pr_warn_once or removing it completely.

I guess the question is, is it considered OK to fail here?

[1] https://lore.kernel.org/all/64b19c8f-e02e-490b-b987-9a996f36be21@gmail.com/
[2] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/
[3] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/
Re: [PATCH] mm: slub: do not warn when allocating slab obj extensions fails
Posted by Suren Baghdasaryan 6 months, 3 weeks ago 
On Wed, May 21, 2025 at 9:21 AM Usama Arif <usamaarif642@gmail.com> wrote:
>
>
>
> On 21/05/2025 17:02, Suren Baghdasaryan wrote:
> > On Wed, May 21, 2025 at 7:25 AM Usama Arif <usamaarif642@gmail.com> 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. Failing this
> >> allocation is not indicative of a bug, so remove the warning.
> >>
> >> 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/
> >> ---
> >> v1 -> v2:
> >> - remove the warning completely. We will have a way in the
> >>   future to indicate that the mem alloc profile is inaccurate.
> >> ---
> >>  mm/slub.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index dc9e729e1d26..06ab9a558b73 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -2102,9 +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),
> >> -                "%s, %s: Failed to create slab extension vector!\n",
> >> -                __func__, s->name))
> >> +           alloc_slab_obj_exts(slab, s, flags, false))
> >
> > I thought we agreed to having pr_warn_once() here. Did I miss something?
> >
>
> I had [1] yesterday but I saw Johannes's mail [2] in and Harry mentioned in [3] that
> failing to allocate the extension vector can happen during normal operations. So I
> thought maybe there are more votes for removing it.
>
> I am ok with either pr_warn_once or removing it completely.

I feel like we should have at least some indication that something
went wrong here.

>
> I guess the question is, is it considered OK to fail here?

Well, it's not ok but not catastrophic either, so warning seems
appropriate to me.

>
> [1] https://lore.kernel.org/all/64b19c8f-e02e-490b-b987-9a996f36be21@gmail.com/
> [2] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/
> [3] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/
Re: [PATCH] mm: slub: do not warn when allocating slab obj extensions fails
Posted by Usama Arif 6 months, 3 weeks ago 

On 21/05/2025 17:29, Suren Baghdasaryan wrote:
> On Wed, May 21, 2025 at 9:21 AM Usama Arif <usamaarif642@gmail.com> wrote:
>>
>>
>>
>> On 21/05/2025 17:02, Suren Baghdasaryan wrote:
>>> On Wed, May 21, 2025 at 7:25 AM Usama Arif <usamaarif642@gmail.com> 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. Failing this
>>>> allocation is not indicative of a bug, so remove the warning.
>>>>
>>>> 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/
>>>> ---
>>>> v1 -> v2:
>>>> - remove the warning completely. We will have a way in the
>>>>   future to indicate that the mem alloc profile is inaccurate.
>>>> ---
>>>>  mm/slub.c | 4 +---
>>>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>> diff --git a/mm/slub.c b/mm/slub.c
>>>> index dc9e729e1d26..06ab9a558b73 100644
>>>> --- a/mm/slub.c
>>>> +++ b/mm/slub.c
>>>> @@ -2102,9 +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),
>>>> -                "%s, %s: Failed to create slab extension vector!\n",
>>>> -                __func__, s->name))
>>>> +           alloc_slab_obj_exts(slab, s, flags, false))
>>>
>>> I thought we agreed to having pr_warn_once() here. Did I miss something?
>>>
>>
>> I had [1] yesterday but I saw Johannes's mail [2] in and Harry mentioned in [3] that
>> failing to allocate the extension vector can happen during normal operations. So I
>> thought maybe there are more votes for removing it.
>>
>> I am ok with either pr_warn_once or removing it completely.
> 
> I feel like we should have at least some indication that something
> went wrong here.
> 
>>
>> I guess the question is, is it considered OK to fail here?
> 
> Well, it's not ok but not catastrophic either, so warning seems
> appropriate to me.
> 
Ok, I will wait a couple of days incase someone has any objections and send
https://lore.kernel.org/all/64b19c8f-e02e-490b-b987-9a996f36be21@gmail.com/
as v3.

Thanks!

>>
>> [1] https://lore.kernel.org/all/64b19c8f-e02e-490b-b987-9a996f36be21@gmail.com/
>> [2] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/
>> [3] https://lore.kernel.org/all/20250520171814.GC773385@cmpxchg.org/

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.