All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jaewon Kim <jaewon31.kim@samsung.com>
Cc: adobriyan@gmail.com, akpm@linux-foundation.org,
	labbott@redhat.com, sumit.semwal@linaro.org, minchan@kernel.org,
	ngupta@vflare.org, sergey.senozhatsky.work@gmail.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	jaewon31.kim@gmail.com
Subject: Re: [RFC PATCH 0/3] meminfo: introduce extra meminfo
Date: Fri, 13 Mar 2020 09:21:22 +0200	[thread overview]
Message-ID: <20200313072122.GD31504@unreal> (raw)
In-Reply-To: <5E6B0E72.7010305@samsung.com>

On Fri, Mar 13, 2020 at 01:39:14PM +0900, Jaewon Kim wrote:
>
>
> On 2020년 03월 11일 16:25, Leon Romanovsky wrote:
> > On Wed, Mar 11, 2020 at 12:44:38PM +0900, Jaewon Kim wrote:
> >> /proc/meminfo or show_free_areas does not show full system wide memory
> >> usage status. There seems to be huge hidden memory especially on
> >> embedded Android system. Because it usually have some HW IP which do not
> >> have internal memory and use common DRAM memory.
> >>
> >> In Android system, most of those hidden memory seems to be vmalloc pages
> >> , ion system heap memory, graphics memory, and memory for DRAM based
> >> compressed swap storage. They may be shown in other node but it seems to
> >> useful if /proc/meminfo shows all those extra memory information. And
> >> show_mem also need to print the info in oom situation.
> >>
> >> Fortunately vmalloc pages is alread shown by commit 97105f0ab7b8
> >> ("mm: vmalloc: show number of vmalloc pages in /proc/meminfo"). Swap
> >> memory using zsmalloc can be seen through vmstat by commit 91537fee0013
> >> ("mm: add NR_ZSMALLOC to vmstat") but not on /proc/meminfo.
> >>
> >> Memory usage of specific driver can be various so that showing the usage
> >> through upstream meminfo.c is not easy. To print the extra memory usage
> >> of a driver, introduce following APIs. Each driver needs to count as
> >> atomic_long_t.
> >>
> >> int register_extra_meminfo(atomic_long_t *val, int shift,
> >> 			   const char *name);
> >> int unregister_extra_meminfo(atomic_long_t *val);
> >>
> >> Currently register ION system heap allocator and zsmalloc pages.
> >> Additionally tested on local graphics driver.
> >>
> >> i.e) cat /proc/meminfo | tail -3
> >> IonSystemHeap:    242620 kB
> >> ZsPages:          203860 kB
> >> GraphicDriver:    196576 kB
> >>
> >> i.e.) show_mem on oom
> >> <6>[  420.856428]  Mem-Info:
> >> <6>[  420.856433]  IonSystemHeap:32813kB ZsPages:44114kB GraphicDriver::13091kB
> >> <6>[  420.856450]  active_anon:957205 inactive_anon:159383 isolated_anon:0
> > The idea is nice and helpful, but I'm sure that the interface will be abused
> > almost immediately. I expect that every driver will register to such API.
> >
> > First it will be done by "large" drivers and after that everyone will copy/paste.
> I thought using it is up to driver developers.
> If it is abused, /proc/meminfo will show too much info. for that device.
> What about a new node, /proc/meminfo_extra, to gather those info. and not
> corrupting original /proc/meminfo.

I don't know if it is applicable for all users, but for the drivers
such info is better to be placed in /sys/ as separate file (for example
/sys/class/net/wlp3s0/*) and driver/core will be responsible to
register/unregister.

It will ensure that all drivers get this info without need to register
and make /proc/meminfo and /proc/meminfo_extra too large.

Thanks

>
> Thank you
> > Thanks
> >
> >
>


  reply	other threads:[~2020-03-13  7:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200311034454epcas1p2ef0c0081971dd82282583559398e58b2@epcas1p2.samsung.com>
2020-03-11  3:44 ` [RFC PATCH 0/3] meminfo: introduce extra meminfo Jaewon Kim
2020-03-11  3:44   ` [RFC PATCH 1/3] proc/meminfo: " Jaewon Kim
2020-03-11  6:18     ` Sergey Senozhatsky
2020-03-11  6:25       ` Sergey Senozhatsky
2020-03-11  6:30         ` Jaewon Kim
2020-03-11  7:36     ` kbuild test robot
2020-03-11  7:51     ` kbuild test robot
2020-03-11  8:55     ` kbuild test robot
2020-03-11 17:35     ` Alexey Dobriyan
2020-03-13  4:53       ` Jaewon Kim
2020-03-11  3:44   ` [RFC PATCH 2/3] mm: zsmalloc: include zs page size in proc/meminfo Jaewon Kim
2020-03-11  3:44   ` [RFC PATCH 3/3] android: ion: include system heap " Jaewon Kim
2020-03-11  7:25   ` [RFC PATCH 0/3] meminfo: introduce extra meminfo Leon Romanovsky
2020-03-13  4:39     ` Jaewon Kim
2020-03-13  7:21       ` Leon Romanovsky [this message]
2020-03-13 15:19   ` Vlastimil Babka
2020-03-13 17:48     ` Leon Romanovsky
2020-03-16  4:07       ` Jaewon Kim
2020-03-16  8:31         ` Leon Romanovsky
2020-03-17  3:04           ` Jaewon Kim
2020-03-17 14:37             ` Leon Romanovsky
2020-03-18  8:58               ` Jaewon Kim
2020-03-18 10:58                 ` Leon Romanovsky
2020-03-20 10:00   ` Dave Young

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=20200313072122.GD31504@unreal \
    --to=leon@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jaewon31.kim@gmail.com \
    --cc=jaewon31.kim@samsung.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sumit.semwal@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.