>Hi Jaewon, > >Please use reply-all! > >I just realized my previous reply went off-list :( Oh I'm very sorry I didn't know that. I just found that I had sent the mail to all as email secret recipient. > >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@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. > >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. 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 ? 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 ? > >> 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.
