All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Jaewon Kim <jaewon31.kim@samsung.com>
Cc: "vbabka@suse.cz" <vbabka@suse.cz>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	YongTaek Lee <ytk.lee@samsung.com>,
	"jaewon31.kim@gmail.com" <jaewon31.kim@gmail.com>
Subject: Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory
Date: Wed, 30 Mar 2022 10:08:24 +0300	[thread overview]
Message-ID: <YkQB6Ah603yPR3qf@kernel.org> (raw)
In-Reply-To: <20220329024620epcms1p7633018e83f54e532761008a60da5254f@epcms1p7>

Hi,

On Tue, Mar 29, 2022 at 11:46:20AM +0900, Jaewon Kim wrote:
> >> > 
> >> >I'm still not following. The reserved region sizes are available in the
> >> >existing memblock debugfs.
> >> >Why the names are important? What is the value of having names for *some*
> >> >of the reserved regions?
> >> 
> >> Hi
> >> 
> >> There are many memory regions in memblock debugfs memory/reserved, and some might
> >> be splited or merged with other region. Among regions in debugfs, we can't find 
> >> the one we defined in device tree. Especially it is difficult to find the region we
> >> described size only without start address.
> >> 
> >> On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure
> >> world, Audio, ETC. To support them, there are many reserved regions described in
> >> device tree. So the name is quite important to recognize a region. And with thename
> >> we can compare reserved memory map with other map.
> >
> >You still didn't describe your use case. What is the problem your patches
> >are trying to solve? Why is it important to know what is the use of particular
> >reserved region? 
> >
> >You propose complex mechanism that seems to fit very particular scenario
> >and sprinkle some calls to this mechanism at random places because you need
> >to "compare reserved memory map with other map".
> >
> >Does not sound convincing to me, sorry.
> 
> As I said serveral times, I want a simple knob showing all reserved
> memory status.  The current debugfs, device tree do not show all those
> information I want. I think you also know that.  i.e. late freed pages,
> splited or merged memblock, address defined at boot time, kernel size,
> ETC. 

I know that there is not much information about reserved memory exposed and
I understand *what* are you trying to achieve. But you never provided
details about *why* you want this information exposed.

I don't mind providing more visibility into reserved memory attributes in
general, but I'd like to see something way more simple and localized.

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2022-03-30  7:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220324065919epcas1p4c79da5f6ec4fa0311409ca24a38785d8@epcas1p4.samsung.com>
2022-03-24  7:01 ` [PATCH 0/8] memblock: introduce memsize showing reserved memory Jaewon Kim
2022-03-24  7:01   ` [PATCH 1/8] " Jaewon Kim
2022-03-24  7:01   ` [PATCH 2/8] memblock: detect hidden memory hole size Jaewon Kim
2022-03-24  7:01   ` [PATCH 3/8] memblock: handle overlapped reserved memory region Jaewon Kim
2022-03-24  7:01   ` [PATCH 4/8] memblock: track memblock changed at early param Jaewon Kim
2022-03-24  7:01   ` [PATCH 5/8] memblock: track kernel size on memsize Jaewon Kim
2022-03-24  7:01   ` [PATCH 6/8] memblock: recognize late free by checking PageReserved Jaewon Kim
2022-03-24  7:01   ` [PATCH 7/8] memblock: print memsize summary information Jaewon Kim
2022-03-24  7:01   ` [PATCH 8/8] memblock: print kernel internal size Jaewon Kim
2022-03-25  7:46   ` [PATCH 0/8] memblock: introduce memsize showing reserved memory Mike Rapoport
2022-03-25  8:38     ` Jaewon Kim
2022-03-27  7:40       ` Mike Rapoport
2022-03-27 13:53         ` Jaewon Kim
2022-03-27 15:15           ` Mike Rapoport
2022-03-29  2:46             ` Jaewon Kim
2022-03-30  7:08               ` Mike Rapoport [this message]
2022-03-30  7:22                 ` Jaewon Kim

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=YkQB6Ah603yPR3qf@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jaewon31.kim@gmail.com \
    --cc=jaewon31.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    --cc=ytk.lee@samsung.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 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.