mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Wang" <00107082@163.com>
To: "Suren Baghdasaryan" <surenb@google.com>
Cc: kent.overstreet@linux.dev, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [BUG?]Data key in /proc/allocinfo is a multiset
Date: Sat, 10 May 2025 00:36:23 +0800 (CST)	[thread overview]
Message-ID: <152dd526.b05a.196b5e7b738.Coremail.00107082@163.com> (raw)
In-Reply-To: <CAJuCfpH4eiSgZqdMTCUOU2VfYezZuLoJefc0wuOWor9eeNzNTA@mail.gmail.com>


At 2025-05-09 23:56:32, "Suren Baghdasaryan" <surenb@google.com> wrote:
>On Thu, May 8, 2025 at 11:10 PM David Wang <00107082@163.com> wrote:
>>
>> Just start a new thread for this[1].
>> There are duplications in /proc/allocinfo where same [file:line]
>> shows up several times:
>>
>> =======================
>>            0        0 ./include/crypto/kpp.h:185 func:kpp_request_alloc
>>            0        0 ./include/crypto/kpp.h:185 func:kpp_request_alloc
>> =======================
>>            0        0 ./include/net/tcp.h:2548 func:tcp_v4_save_options
>>            0        0 ./include/net/tcp.h:2548 func:tcp_v4_save_options
>> =======================
>>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
>> =======================
>>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
>>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
>
>Yep, that happens when an inlined function allocates memory. It ends
>up inlined in different locations. Usually that's done by allocation
>helper functions.
>To fix this we need to wrap these allocator helpers with alloc_hooks:
>
>-static inline void *iommu_alloc_pages_node(int nid, gfp_t gfp, int order)
>+static inline void *iommu_alloc_pages_node_noprof(int nid, gfp_t gfp,
>int order)
>{
>-        struct page *page = alloc_pages_node(nid, gfp | __GFP_ZERO,
>order);  struct skcipher_request *req;
>+        struct page *page = alloc_pages_node_noprof(nid, gfp |
>__GFP_ZERO, order);  struct skcipher_request *req;
>...
>}
>+#define iommu_alloc_pages_node(...)
>alloc_hooks(iommu_alloc_pages_node_noprof(__VA_ARGS__))
>
>See 2c321f3f70bc "mm: change inlined allocation helpers to account at
>the call site" for examples of how this was done before.
>Thanks,
>Suren.

Thanks for clarifying this, seems like a never-ending work...... >_<|||

>
>> ...
>>
>> The duplication make parsing tools a little bit more complicated:
>> the numbers need to be added up, group by key
>>        81920       20 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node 20
>>      1441792      352 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node 352
>>
>> The script for checking:
>> ```
>> #!/bin/env python
>> def fetch():
>>     r = {}
>>     with open("/proc/allocinfo") as f:
>>         for l in f:
>>             f = l.strip().split()[2]
>>             if f not in r: r[f]=[]
>>             r[f].append(l)
>>     keys = []
>>     for f, ls in r.items():
>>         if len(ls) > 1: keys.append(f)
>>     keys.sort()
>>     for f in keys:
>>         print "======================="
>>         for l in r[f]: print l,
>>
>> fetch()
>> ```
>>
>> Thanks
>> David
>>
>> [1]. https://lore.kernel.org/lkml/531adbba.b537.196b0868a8c.Coremail.00107082@163.com/
>>

  reply	other threads:[~2025-05-09 16:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09  6:10 David Wang
2025-05-09 15:56 ` Suren Baghdasaryan
2025-05-09 16:36   ` David Wang [this message]
2025-05-09 16:57     ` Suren Baghdasaryan
2025-05-09 17:31       ` Kent Overstreet

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=152dd526.b05a.196b5e7b738.Coremail.00107082@163.com \
    --to=00107082@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=surenb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®