Re: [PATCH RFC] alloc_tag: add option to pick the first codetag along callchain

["David Wang" <00107082@163.com>]

At 2026-01-06 18:54:36, "Kent Overstreet" <kent.overstreet@linux.dev> wrote:
>On Tue, Jan 06, 2026 at 11:50:36AM +0800, David Wang wrote:
>> At 2026-01-06 05:12:48, "Suren Baghdasaryan" <surenb@google.com> wrote:
>> >On Mon, Dec 15, 2025 at 10:44 PM David Wang <00107082@163.com> wrote:
>> >>
>> >> When tracking memory allocation for some specific function,
>> >> picking the first codetag is more desired, because there
>> >> is no need to track down all allocation sites in the call
>> >> graph and change them to _noprof version, which is quite
>> >> inflexible when the call graph is complex.
>> >>
>> >> For example, consider a simple graph:
>> >>
>> >> A ---> B ---> C ===> D
>> >>        E ---> C
>> >>
>> >> ===> means a call with codetag
>> >> ---> means a call without codetag
>> >>
>> >> To profiling memory allocation for A, the call graph needs
>> >> to be changed to
>> >> A ===> B ---> C ---> D
>> >>        E ===> C
>> >> Three call sites needs to be changed.
>> >>
>> >> But if pick the first codetag, only one change is needed.
>> >> A ===> B ---> C ===> D
>> >>        E ---> C
>> >>
>> >> The drawback is some accounting for C is splited to A,
>> >> making the number not accurate for C. (But the overall
>> >> accounting is still the same.)
>> >>
>> >> This is useful when debug memory problems, not meant for
>> >> production usage though.
>> >
>> >Hi David,
>> >Sorry for the delay. Do you have specific examples when allocation
>> >needs to be accounted at the highest level
>> Hi, 
>> 
>> I do not have a very convincing  practical example yet. :(
>> I started to think about this in this thread[1], debugging possible memory leak in cephfs.
>> If modules want to account its memory usage, they can plant codetags in their codepath
>> without worrying about codetags deeper in the code chain.
>> 
>> And I noticed that some callsites' memory usage is incomplete, because its accounting
>> is split by codetags deeper in the code chain 
>> For example, on my system, I have
>> 512        1 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init
>> but if pick first codetag, I would have
>> 20992        10 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init
>> 
>> One call chain  
>>     usb_hub_init==>alloc_workqueue--->__alloc_workqueue -->alloc_node_nr_active==>kzalloc_node
>> has two codetags, and its memory is not accounted to usb drivers.
>> 
>> If interested in module's memory usage,  picking the first codetag would be preferred, I guess.
>
>Is an end user going to be able to do anything with such an option?

I think the option could be used for testing drivers/modules, enable this option, the memory usage for
a module is more accurate. 


>
>Your option just flattens the accounting - this results in incorrect
>accounting, not just insufficiently fine grained - and incorrect in a
>way that's harder to notice and find and fix.


I agree, the accounting would be incorrect for alloc sites down the callchain, and would confuse things.
When the call chain has more than one codetag, correct accounting for one codetag would always mean incorrect
accounting for other codetags, right? But I don't think picking the first tag would make the accounting totally incorrect. 

In a perfect world, maybe we can make sure there is only one codetag in any callchains. But
current code base has several situations where a _noprof version calls indirectly an alloc without _noprof,
as the usb_hub_init example I mentioned above: alloc_workqueue calls kzalloc_node indirectly.




>
>How many times have you gone down the wrong rabbit hole because your
>tools were subtly lying to you? This is something we really want to
>avoid.

Totally agree.
I used to sum by filepath prefix to aggregate memory usage for drivers.
Take usb subsystem for example,  on my system, the data say my usb drivers use up 200k memory,
and if pick first codetag, the data say ~350K.   Which one is lying, or are those two both lying. I am  confused.

I think this also raises the question of what is the *correct* way to make use of /proc/allocinfo...


>
>The fact that you have to be explicit about where the accounting happens
>via _noprof is a feature, not a bug :)

But it is tedious... :(