>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.
Oh good thing, I did not know this patch. Thanks.
By the way, I've tried to get memblock/memory and kernel log from a device based on
v6.6.17 kernel device, to see upstream patches above.
memblok/memory does not show region for 0x00000000_80000000..0x0x00000000_8195ffff.
0: 0x0000000081960000..0x00000000819fffff 0 NONE
The kernel log shows information for 0x0000000080000000..0x00000000813fffff, but
we don't see information for 0x0000000081400000..0x000000008195ffff from kernel log.
(I removed the name.)
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DD
A smart parser should gather these kernel log and memblock/memory log and should show
log like my memsize logic shows below.
0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
Thank you
Jaewon
>
>--
>Sincerely yours,
>Mike.
