linux-kernel - Re: [PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4b78ebee.26dc.196adb5ce7e.Coremail.00107082@163.com>
Date: Thu, 8 May 2025 10:24:55 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Suren Baghdasaryan" <surenb@...gle.com>
Cc: kent.overstreet@...ux.dev, 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 07:42:56, "Suren Baghdasaryan" <surenb@...gle.com> 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.

Thanks for the quick feedback~ 
 Agree that this would cause troubles to userspace  tools,
and also it add more performance impact for profiling.

David

>
>All that said, I'm open to suggestions if there is a way to
>incorporate cumulative counters that would not tax all other usecases
>that do not need them.
>
>>
>>
>> FYI
>> David