>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@xxxxxxxxxxx>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@xxxxxxxxxx/#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. 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. 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. BR Jaewon Kim > >-- >Sincerely yours, >Mike.
