On Fri, Feb 16, 2024 at 1:02 AM Suren Baghdasaryan [off-list ref] wrote:

On Thu, Feb 15, 2024 at 5:27 PM Kent Overstreet
[off-list ref] wrote:

quoted

On Thu, Feb 15, 2024 at 08:22:44PM -0500, Pasha Tatashin wrote:

quoted

On Thu, Feb 15, 2024 at 8:00 PM Kent Overstreet
[off-list ref] wrote:

quoted

On Thu, Feb 15, 2024 at 04:54:38PM -0800, Andrew Morton wrote:

quoted

On Mon, 12 Feb 2024 13:38:59 -0800 Suren Baghdasaryan [off-list ref] wrote:

quoted

+Example output.
+
+::
+
+    > cat /proc/allocinfo
+
+      153MiB     mm/slub.c:1826 module:slub func:alloc_slab_page
+     6.08MiB     mm/slab_common.c:950 module:slab_common func:_kmalloc_order
+     5.09MiB     mm/memcontrol.c:2814 module:memcontrol func:alloc_slab_obj_exts
+     4.54MiB     mm/page_alloc.c:5777 module:page_alloc func:alloc_pages_exact
+     1.32MiB     include/asm-generic/pgalloc.h:63 module:pgtable func:__pte_alloc_one

I don't really like the fancy MiB stuff.  Wouldn't it be better to just
present the amount of memory in plain old bytes, so people can use sort
-n on it?

They can use sort -h on it; the string_get_size() patch was specifically
so that we could make the output compatible with sort -h

quoted

And it's easier to tell big-from-small at a glance because
big has more digits.

Also, the first thing any sort of downstream processing of this data is
going to have to do is to convert the fancified output back into
plain-old-bytes.  So why not just emit plain-old-bytes?

If someone wants the fancy output (and nobody does) then that can be
done in userspace.

I like simpler, more discoverable tools; e.g. we've got a bunch of
interesting stuff in scripts/ but it doesn't get used nearly as much -
not as accessible as cat'ing a file, definitely not going to be
installed by default.

I also prefer plain bytes instead of MiB. A driver developer that
wants to verify up-to the byte allocations for a new data structure
that they added is going to be disappointed by the rounded MiB
numbers.

That's a fair point.

quoted

The data contained in this file is not consumable without at least
"sort -h -r", so why not just output bytes instead?

There is /proc/slabinfo  and there is a slabtop tool.
For raw /proc/allocinfo we can create an alloctop tool that would
parse, sort and show data in human readable format based on various
criteria.

We should also add at the top of this file "allocinfo - version: 1.0",
to allow future extensions (i.e. column for proc name).

How would we feel about exposing two different versions in /proc? It
should be a pretty minimal addition to .text.

Personally, I hate trying to count long strings digits by eyeball...

Maybe something like this work for everyone then?:

s/work/would work

making too many mistakes. time for bed...

160432128 (153MiB)     mm/slub.c:1826 module:slub func:alloc_slab_page