MIME-Version: 1.0
References: <20230206142714.4151047-1-liumartin@google.com>
 <CAL_JsqKA8pBess-zLA_2n0p8q=NBuY0EGA7qALKabwJA8ZRwrA@mail.gmail.com>
 <CAASV4h5ANYTJUN3gQxuLxeKMknyoyt7-YTxRRMcjrQXRrVRi5Q@mail.gmail.com> <20230207210458.GA4142905-robh@kernel.org>
In-Reply-To: <20230207210458.GA4142905-robh@kernel.org>
From:   Martin Liu <liumartin@google.com>
Date:   Wed, 8 Feb 2023 16:59:50 +0800
Message-ID: <CAASV4h4u7FZGMJFscGMbY8nLaWzq2stPc3YxpSVmLCq52V=Gmg@mail.gmail.com>
Subject: Re: [PATCH] of: reserved-mem: expose reserved-mem details via debugfs
To:     Rob Herring <robh@kernel.org>
Cc:     frowand.list@gmail.com, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, surenb@google.com,
        minchan@kernel.org, tkjos@google.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Feb 8, 2023 at 5:05 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Feb 08, 2023 at 01:05:25AM +0800, Martin Liu wrote:
> > On Mon, Feb 6, 2023 at 11:12 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Mon, Feb 6, 2023 at 8:27 AM Martin Liu <liumartin@google.com> wrote:
> > > >
> > > > It's important to know reserved-mem information in mobile world
> > > > since reserved memory via device tree keeps increased in platform
> > > > (e.g., 45% in our platform). Therefore, it's crucial to know the
> > > > reserved memory sizes breakdown for the memory accounting.
> > > >
> > > > This patch shows the reserved memory breakdown under debugfs to
> > > > make them visible.
> > > >
> > > > Below is an example output:
> > > > cat $debugfs/reserved_mem/show
> > > > 0x00000009fc400000..0x00000009ffffffff (   61440 KB )   map     reusable test1
> > > > 0x00000009f9000000..0x00000009fc3fffff (   53248 KB )   map     reusable test2
> > > > 0x00000000ffdf0000..0x00000000ffffffff (    2112 KB )   map non-reusable test3
> > > > 0x00000009f6000000..0x00000009f8ffffff (   49152 KB )   map     reusable test4
> > > > ...
> > > > 0x00000000fd902000..0x00000000fd909fff (      32 KB ) nomap non-reusable test38
> > > > 0x00000000fd90a000..0x00000000fd90bfff (       8 KB ) nomap non-reusable test39
> > > > Total 39 regions, 1446140 KB
> > >
> > > This information is pretty much static, why not just print it during
> > > boot? It's also just spitting out information that's straight from the
> > > DT which is also available to userspace (flattened and unflattened).
> >
> > IIUC, for dynamic allocation cases, we can't get actual allocation layout
> > from DT.
>
> Right, so whomever does the allocation should print that out.
>
> >  Also, there could be some adjustment from memblock
> > (ex. alignment). Therefore, printing it out from the reserved_mem would
> > be more clear.
>
> If memblock is adjusting, then shouldn't memblock print out the
> addresses?

Yup, memblock can print out the address with _RET_IP_when the debug is on.
In our case, the _RET_IP_ will be early_init_dt_reserve_memory_arch so it's not
useful to find the memory owner. Thus, printing it out in of_reserved_mem
module will be more clear and simple.
>
> > However, as you mentioned, once the allocation is done, it should be pretty
> > static. Thus, printing it during boot should be reasonable. If so, we
> > could print
> > them out in fdt_init_reserved_mem() like below. Is my understanding correct?
>
> That looks mostly fine to me. If we can do it with the unflattened tree,
> that would be better. I'm not sure off hand if that works here and you
> are just incorrectly using of_get_flat_dt_prop() still, or if it is
> indeed too early.

Yup, it's too early when fdt_init_reserved_mem() is called. I thought
that is also
why nomap and prop values are using of_get_flat_dt_prop() to get the property
content in fdt_init_reserved_mem() as well.

Another thing is we should use pr_info() to print them out as they are not the
debug information. They're the memory layout we really want to know during
the boot.

Please let me know if there are any concerns. If not, I'll send a V2
patch. Thanks.

Martin
>
> Rob