From: Usama Arif <usamaarif642@gmail.com>
To: Suren Baghdasaryan <surenb@google.com>, Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev,
hannes@cmpxchg.org, rientjes@google.com,
roman.gushchin@linux.dev, harry.yoo@oracle.com,
shakeel.butt@linux.dev, 00107082@163.com,
pasha.tatashin@soleen.com, souravpanda@google.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] alloc_tag: mark inaccurate allocation counters in /proc/allocinfo output
Date: Wed, 10 Sep 2025 17:02:37 -0400 [thread overview]
Message-ID: <e073e41d-3317-49a9-a2ee-c0e8def66dcd@gmail.com> (raw)
In-Reply-To: <CAJuCfpFf+D1C9esHXpR5WaJ_4=JmvZkYQMWY7KVYf42JLDTFZQ@mail.gmail.com>
On 10/09/2025 15:50, Suren Baghdasaryan wrote:
> On Tue, Sep 9, 2025 at 11:25 PM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> On 9/10/25 01:49, Suren Baghdasaryan wrote:
>>> While rare, memory allocation profiling can contain inaccurate counters
>>> if slab object extension vector allocation fails. That allocation might
>>> succeed later but prior to that, slab allocations that would have used
>>> that object extension vector will not be accounted for. To indicate
>>> incorrect counters, mark them with an asterisk in the /proc/allocinfo
>>> output.
>>> Bump up /proc/allocinfo version to reflect change in the file format.
>>
>> Since it's rare, is it worth the trouble?
>
> Apparently they are seen in Meta's fleet which instigated this thread:
> https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/
>
Yes it happens on memory bound services!
>>
>>> Example output with invalid counters:
>>> allocinfo - version: 2.0
>>> 0 0 arch/x86/kernel/kdebugfs.c:105 func:create_setup_data_nodes
>>> 0 0 arch/x86/kernel/alternative.c:2090 func:alternatives_smp_module_add
>>> 0* 0* arch/x86/kernel/alternative.c:127 func:__its_alloc
>>> 0 0 arch/x86/kernel/fpu/regset.c:160 func:xstateregs_set
>>> 0 0 arch/x86/kernel/fpu/xstate.c:1590 func:fpstate_realloc
>>> 0 0 arch/x86/kernel/cpu/aperfmperf.c:379 func:arch_enable_hybrid_capacity_scale
>>> 0 0 arch/x86/kernel/cpu/amd_cache_disable.c:258 func:init_amd_l3_attrs
>>> 49152* 48* arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create
>>> 32768 1 arch/x86/kernel/cpu/mce/genpool.c:132 func:mce_gen_pool_create
>>> 0 0 arch/x86/kernel/cpu/mce/amd.c:1341 func:mce_threshold_create_device
>>>
>>> Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
>>
>> Here a link might have been helpful :)
>
> Right, here it is and suggestion is in the last paragraph:
> https://lore.kernel.org/all/20250519160846.GA773385@cmpxchg.org/
>
>>
>>> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
>>> ---
Acked-by: Usama Arif <usamaarif642@gmail.com>
>>> Patch is based on mm-new.
>>>
>>> include/linux/alloc_tag.h | 12 ++++++++++++
>>> include/linux/codetag.h | 5 ++++-
>>> lib/alloc_tag.c | 7 +++++--
>>> mm/slub.c | 2 ++
>>> 4 files changed, 23 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
>>> index 9ef2633e2c08..d40ac39bfbe8 100644
>>> --- a/include/linux/alloc_tag.h
>>> +++ b/include/linux/alloc_tag.h
>>> @@ -221,6 +221,16 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes)
>>> ref->ct = NULL;
>>> }
>>>
>>> +static inline void alloc_tag_set_inaccurate(struct alloc_tag *tag)
>>> +{
>>> + tag->ct.flags |= CODETAG_FLAG_INACCURATE;
>>> +}
>>> +
>>> +static inline bool alloc_tag_is_inaccurate(struct alloc_tag *tag)
>>> +{
>>> + return !!(tag->ct.flags & CODETAG_FLAG_INACCURATE);
>>> +}
>>> +
>>> #define alloc_tag_record(p) ((p) = current->alloc_tag)
>>>
>>> #else /* CONFIG_MEM_ALLOC_PROFILING */
>>> @@ -230,6 +240,8 @@ static inline bool mem_alloc_profiling_enabled(void) { return false; }
>>> static inline void alloc_tag_add(union codetag_ref *ref, struct alloc_tag *tag,
>>> size_t bytes) {}
>>> static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {}
>>> +static inline void alloc_tag_set_inaccurate(struct alloc_tag *tag) {}
>>> +static inline bool alloc_tag_is_inaccurate(struct alloc_tag *tag) { return false; }
>>> #define alloc_tag_record(p) do {} while (0)
>>>
>>> #endif /* CONFIG_MEM_ALLOC_PROFILING */
>>> diff --git a/include/linux/codetag.h b/include/linux/codetag.h
>>> index 457ed8fd3214..8ea2a5f7c98a 100644
>>> --- a/include/linux/codetag.h
>>> +++ b/include/linux/codetag.h
>>> @@ -16,13 +16,16 @@ struct module;
>>> #define CODETAG_SECTION_START_PREFIX "__start_"
>>> #define CODETAG_SECTION_STOP_PREFIX "__stop_"
>>>
>>> +/* codetag flags */
>>> +#define CODETAG_FLAG_INACCURATE (1 << 0)
>>> +
>>> /*
>>> * An instance of this structure is created in a special ELF section at every
>>> * code location being tagged. At runtime, the special section is treated as
>>> * an array of these.
>>> */
>>> struct codetag {
>>> - unsigned int flags; /* used in later patches */
>>> + unsigned int flags;
>>> unsigned int lineno;
>>> const char *modname;
>>> const char *function;
>>> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>>> index e9b33848700a..a7f15117c759 100644
>>> --- a/lib/alloc_tag.c
>>> +++ b/lib/alloc_tag.c
>>> @@ -80,7 +80,7 @@ static void allocinfo_stop(struct seq_file *m, void *arg)
>>> static void print_allocinfo_header(struct seq_buf *buf)
>>> {
>>> /* Output format version, so we can change it. */
>>> - seq_buf_printf(buf, "allocinfo - version: 1.0\n");
>>> + seq_buf_printf(buf, "allocinfo - version: 2.0\n");
>>> seq_buf_printf(buf, "# <size> <calls> <tag info>\n");
>>> }
>>>
>>> @@ -90,7 +90,10 @@ static void alloc_tag_to_text(struct seq_buf *out, struct codetag *ct)
>>> struct alloc_tag_counters counter = alloc_tag_read(tag);
>>> s64 bytes = counter.bytes;
>>>
>>> - seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls);
>>> + if (unlikely(alloc_tag_is_inaccurate(tag)))
>>> + seq_buf_printf(out, "%11lli* %7llu* ", bytes, counter.calls);
>>> + else
>>> + seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls);
>>> codetag_to_text(out, ct);
>>> seq_buf_putc(out, ' ');
>>> seq_buf_putc(out, '\n');
>>> diff --git a/mm/slub.c b/mm/slub.c
>>> index af343ca570b5..9c04f29ee8de 100644
>>> --- a/mm/slub.c
>>> +++ b/mm/slub.c
>>> @@ -2143,6 +2143,8 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
>>> */
>>> if (likely(obj_exts))
>>> alloc_tag_add(&obj_exts->ref, current->alloc_tag, s->size);
>>> + else
>>> + alloc_tag_set_inaccurate(current->alloc_tag);
>>> }
>>>
>>> static inline void
>>>
>>> base-commit: f4e8f46973fe0c0f579944a37e96ba9efbe00cca
>>
next prev parent reply other threads:[~2025-09-10 21:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 23:49 [PATCH 1/1] alloc_tag: mark inaccurate allocation counters in /proc/allocinfo output Suren Baghdasaryan
2025-09-10 5:18 ` Shakeel Butt
2025-09-10 6:25 ` Vlastimil Babka
2025-09-10 14:50 ` Suren Baghdasaryan
2025-09-10 21:02 ` Usama Arif [this message]
2025-09-11 12:30 ` Johannes Weiner
2025-09-11 15:03 ` David Wang
2025-09-11 15:47 ` [PATCH " Yueyang Pan
2025-09-11 16:00 ` Usama Arif
2025-09-11 16:18 ` Suren Baghdasaryan
2025-09-11 17:25 ` Yueyang Pan
2025-09-11 17:35 ` David Wang
2025-09-11 18:13 ` Suren Baghdasaryan
2025-09-11 18:51 ` Yueyang Pan
2025-09-11 19:59 ` Suren Baghdasaryan
2025-09-11 21:31 ` Andrew Morton
2025-09-12 0:25 ` Suren Baghdasaryan
2025-09-12 2:02 ` David Wang
2025-09-12 10:52 ` Yueyang Pan
2025-09-12 19:38 ` Suren Baghdasaryan
2025-09-15 18:31 ` Yueyang Pan
2025-09-15 23:04 ` Suren Baghdasaryan
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=e073e41d-3317-49a9-a2ee-c0e8def66dcd@gmail.com \
--to=usamaarif642@gmail.com \
--cc=00107082@163.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=souravpanda@google.com \
--cc=surenb@google.com \
--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.