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

[Mike Rapoport <rppt@kernel.org>]

Hi Jaewon,

Please use reply-all!

I just realized my previous reply went off-list :(

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:
> >> >> >--------- Original Message ---------
> >> >> >Sender : 김재원 <jaewon31.kim@samsung.com>System Performance Lab.(MX)/삼성전자
> >> >> >Date   : 2024-05-21 11:40 (GMT+9)
> >> >> >Title  : [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory
> >> >> >?
> >> >> >Some of memory regions can be reserved for a specific purpose. They are
> >> >> >usually defined through reserved-memory in device tree. If only size
> >> >> >without address is specified in device tree, the address of the region
> >> >> >will be determined at boot time.
> >> >> >
> >> >> >We may find the address of the memory regions through booting log, but
> >> >> >it does not show all. And it could be hard to catch the very beginning
> >> >> >log. The memblock_dump_all shows all memblock status but it does not
> >> >> >show region name and its information is difficult to summarize.
> >> >> >
> >> >> >This patch introduce a debugfs node, memblock/memsize, to see reserved
> >> >> >memory easily.
> >> >> 
> >> >> 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?

> And it does not show some information like kernel init size, late free
> pages. AFAIK if some memblocks are merged to a memblock data structure,
> the debugfs memblock API show it a one memblock rather than showing what
> each memblock request.

The reason to merge reserved regions is to save memory and CPU and in vast
majority of cases it is not important from where memblock_reserve() was
called. If it's really important to keep some of the reservations distinct,
it can be achieved by e.g. using .flags field in the reserved regions.

Your repost of the patches still does not address my comment from two
years ago:

	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".

As I said then, 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 with a clear description what problem it solves and how it works
in a general case.
 
> BR
> Jaewon Kim

-- 
Sincerely yours,
Mike.