[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <289b58f1.352d.196addbf31d.Coremail.00107082@163.com>
Date: Thu, 8 May 2025 11:06:35 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc: "Suren Baghdasaryan" <surenb@...gle.com>, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] alloc_tag: avoid mem alloc and iter reset when reading
allocinfo
At 2025-05-08 08:01:55, "Kent Overstreet" <kent.overstreet@...ux.dev> wrote:
>On Wed, May 07, 2025 at 11:42:56PM +0000, Suren Baghdasaryan wrote:
>> On Wed, May 7, 2025 at 6:19 PM David Wang <00107082@....com> wrote:
>> >
>> > 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.
>>
>> Yeah, my issue with cumulative counters is that while they might be
>> useful for some analyses, most usecases would probably not benefit
>> from them while sharing the performance overhead. OTOH making it
>> optional with a separate CONFIG that affects the content of the
>> /proc/allocinfo seems like a bad idea to me. Userspace parsers now
>> would have to check not only the file version but also whether this
>> kernel config is enabled, or handle a possibility of an additional
>> column in the output. Does not seem like a good solution to me.
>
>Yeah, I don't see much benefit for cumulative counters over just running
>a profiler.
>
>Running a profiler is always the first thing you should do when you care
>about CPU usage, that's always the thing that will give you the best
>overall picture. If memory allocations are an issue, they'll show up
>there.
>
>But generally they're not, because slub is _really damn fast_. People
>generally worry about memory allocation overhead a bit too much.
>
>(Memory _layout_, otoh, avoid pointer chasing - that's always worth
>worrying about, but cumulative counters won't show you that).
Thanks for the feedback~
I agree that memory allocation normally dose not take major part of a profiling report,
even profiling a fio test, kmem_cache_alloc only takes ~1% perf samples.
I don't know why I have this "the less memory allocation, the better' mindset, maybe
I was worrying about memory fragmentation, or something else I learned on some "textbook",
To be honest, I have never had real experience with those worries....
David
Powered by blists - more mailing lists