From: "David Wang" <00107082@163.com>
To: surenb@google.com, kent.overstreet@linux.dev, akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re:[PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo
Date: Thu, 8 May 2025 02:19:34 +0800 (CST) [thread overview]
Message-ID: <a0ebf2e.b422.196abf97373.Coremail.00107082@163.com> (raw)
In-Reply-To: <20250507175500.204569-1-00107082@163.com>
Hi,
Just want to share how I notice those memory allocation behaivors: the cumulative counters~!
With cumulative counters, I can identify which module keeps alloc/free memory, by the ratio between
cumulative calls and remaining calls, and maybe an optimization could be applied.
Following is top16 I got on my system:
+-----------------------------------------+-------+------------------+--------------------+
| alloc | calls | cumulative calls | ratio |
+-----------------------------------------+-------+------------------+--------------------+
| fs/seq_file.c:584 | 2 | 18064825 | 9032412.5 |
| fs/seq_file.c:38 | 5 | 18148288 | 3629657.6 |
| fs/seq_file.c:63 | 15 | 18153271 | 1210218.0666666667 |
| net/core/skbuff.c:577 | 9 | 10679975 | 1186663.888888889 |
| net/core/skbuff.c:658 | 21 | 11013437 | 524449.380952381 |
| fs/select.c:168 | 7 | 2831226 | 404460.85714285716 |
| lib/alloc_tag.c:51 | 1 | 340649 | 340649.0 | <--- Here I started
| kernel/signal.c:455 | 1 | 300730 | 300730.0 |
| fs/notify/inotify/inotify_fsnotify.c:96 | 1 | 249831 | 249831.0 |
| fs/ext4/dir.c:675 | 3 | 519734 | 173244.66666666666 |
| drivers/usb/host/xhci.c:1555 | 4 | 126402 | 31600.5 |
| fs/locks.c:275 | 36 | 986957 | 27415.472222222223 |
| fs/proc/inode.c:502 | 3 | 63753 | 21251.0 |
| fs/pipe.c:125 | 123 | 2143378 | 17425.837398373984 |
| net/core/scm.c:84 | 3 | 43267 | 14422.333333333334 |
| fs/kernel_read_file.c:80 | 2 | 26910 | 13455.0 |
+-----------------------------------------+-------+------------------+--------------------+
I think this is another "good" usage for cumulative counters: if a module just keeps alloc/free memory,
maybe it is good to move the memory alloc/free to somewhere less frequent.
In the case of this patch, a memory allocation for each read-calls, can be moved to opan-calls.
If interested, I can re-send the patch for cumulative counters for further discussions.
FYI
David
next prev parent reply other threads:[~2025-05-07 18:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 17:55 [PATCH] " David Wang
2025-05-07 18:19 ` David Wang [this message]
2025-05-07 23:42 ` Suren Baghdasaryan
2025-05-08 0:01 ` Kent Overstreet
2025-05-08 3:06 ` David Wang
2025-05-08 3:31 ` Kent Overstreet
2025-05-08 3:35 ` David Wang
2025-05-08 4:07 ` Kent Overstreet
2025-05-08 5:51 ` David Wang
2025-05-08 13:33 ` Kent Overstreet
2025-05-08 16:24 ` David Wang
2025-05-08 16:34 ` Kent Overstreet
2025-05-08 16:58 ` David Wang
2025-05-08 17:17 ` David Wang
2025-05-08 17:26 ` Kent Overstreet
2025-05-08 2:24 ` David Wang
2025-05-07 23:36 ` Suren Baghdasaryan
2025-05-08 3:10 ` David Wang
2025-05-08 15:32 ` David Wang
2025-05-08 21:41 ` Suren Baghdasaryan
2025-05-09 5:53 ` [PATCH 2/2] alloc_tag: keep codetag iterator cross read() calls David Wang
2025-05-09 17:34 ` Suren Baghdasaryan
2025-05-09 17:45 ` David Wang
2025-05-09 17:39 ` [PATCH v2 2/2] alloc_tag: keep codetag iterator active between " David Wang
2025-05-09 18:33 ` Tim Chen
2025-05-09 19:36 ` Suren Baghdasaryan
2025-05-09 19:46 ` Tim Chen
2025-05-09 20:46 ` Suren Baghdasaryan
2025-05-09 21:15 ` Suren Baghdasaryan
2025-05-10 3:10 ` David Wang
2025-05-10 3:30 ` Suren Baghdasaryan
2025-05-10 3:58 ` David Wang
2025-05-10 4:03 ` Suren Baghdasaryan
2025-05-10 3:35 ` David Wang
2025-05-10 3:25 ` David Wang
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=a0ebf2e.b422.196abf97373.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=linux-mm@kvack.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