Re: (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory

[Mike Rapoport <rppt@kernel.org>]

On Mon, May 27, 2024 at 10:35:04AM +0900, Jaewon Kim wrote:
> >On Fri, May 24, 2024 at 06:07:15PM +0900, Jaewon Kim wrote:
> >> >On Tue, May 21, 2024 at 07:17:53PM +0900, Jaewon Kim wrote:
> >> >> >On Tue, May 21, 2024 at 11:53:29AM +0900, Jaewon Kim wrote:
> >> >> >> 
> >> >> >> This is actually RESEND as it was introduced 2 years ago.
> >> >> >> Please refer to https://lore.kernel.org/linux-mm/YkQB6Ah603yPR3qf@kernel.org/#t
> >> >> >> 
> >> >> >> > But you never provided details about *why* you want this information exposed.
> >> >> >> 
> >> >> >> For your question, I'd like to say ;
> >> >> >> We can see the same format and exact information between different version of kernel status.
> >> >> >> 
> >> >> >> 1) Internally we can check if the reserved memory changes.
> >> >> >> 2) Externally we can communicate between chipset vendors and OEM, with a same format.
> >> >> >
> >> >> >Why the existing debugfs interface is not sufficient?
> >> >> 
> >> >> debugfs/memblock/memory & debugfs/memblock/reserved have changed its
> >> >> format but still does not show name, reusable, kernel size.  If memory is
> >> >> reserved from memblock, and did not freed back to memblock. Memblock does
> >> >> not know even after the memory is freed to system.  I think a simple
> >> >> debug interface is needed to easily communicate with others or compare
> >> >> different SW releases.
> >> >
> >> >I still don't understand what problem are you trying to solve with these
> >> >patches. 
> >> 
> >> I think we need a common API to easily see the reserved memory status.
> >> Through MemTotal on /proc/meminfo, we can only see only the total size
> >> of reserved memory. We don't how big kernel init size within the the
> >> total size. I think this really helps to compare different kernel and
> >> communicate with others.
> >
> > As was already mentioned on this thread, something like
> >
> > $ dmesg | grep Memory:
> > [    0.000000] Memory: 8058204K/8388608K available (35392K kernel code, 8706K rwdata, 23320K rodata, 16832K init, 848K bss, 297636K reserved, 32768K cma-reserved)
> >
> > already shows init, rodata and bss sizes.
> >
> > And size -A vmlinux provides detailed breakdown of the kernel image into
> > sections.
> > 
> >> I think the debugfs API or early boot log shows quite much information
> >> for the reserved memory information defined in device tree. But it is
> >> difficult to see after boot, as the boot log already was removed ouf of
> >> the kernel log buffer.
> >
> > Kernel log is persisted, isn't it?
> 
> Early kernel log is removed after other log is written to the log buffer. I may
> not be able to get it, after waiting for the target device is ready to be
> connected from host PC. I wanted to keep that information.
> 
> Actually the commit aeb9267eb6b1 ("of: reserved-mem: print out reserved-mem
> details during boot") seems to show most of information if I can get the early
> boot log.

Unless the kernel log is stored on the target you need to redirect
target's console to a file on the host, then all of the boot log will be
accessible on the host.

Then with memblock=debug kernel parameter you'll be able to get much more
information about memblock reservations.
 
> If you don't mind, let me ask one question. How can we easily find the undefined
> DRAM memory regions in kernel persective. Do we have to look into the debugfs 
> memblock/memory and combine the information with the kernel log information?
> 
> case1) Actual DRAM is mapped as two regions like,
>    2GB @ 0x00000000_80000000 and 6GB @ 0x00000008_80000000,
>    how can we find the hole, 0x00000000_80000000--0x00000008_7FFFFFFF ?

The actual memory banks reported to Linux are shown at
debugfs/memblock/memory
 
> case2) If some region is already carved out at bootloader stage like.
>    0x00000000_81200000-0x00000000_812FFFFF was not initinally on memblock.
>    0x00000000_80000000-0x00000000_81200000 was removed as no-map through device tree.
>    how can we find the hole, 0x00000000_81200000-0x00000000_812FFFFF ?

nomap regions are shown in debugfs/memblock/memory as NOMAP.

-- 
Sincerely yours,
Mike.