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