| Message ID | 20240521023957.2587005-1-jaewon31.kim@samsung.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | memblock: introduce memsize showing reserved memory | expand |
>--------- 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. > >Here's an example > >$ cat debugfs/memblock/memsize > >0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma >0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx >... >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx > >Reserved? ? : 1223856 KB > .kernel? ? :? 275208 KB >? .text? ? :? 16576 KB >? .rwdata? :? ? 1963 KB >? .rodata? :? 11920 KB >? .bss? ? ? :? ? 2450 KB >? .memmap? :? 186368 KB >? .etc? ? ? :? 55933 KB > .unusable? :? 948648 KB >System? ? ? : 11359056 KB > .common? ? : 10306384 KB > .reusable? : 1052672 KB >Total? ? ? : 12582912 KB ( 12288.00 MB ) > >Jaewon Kim (10): >? memblock: introduce memsize showing reserved memory >? memblock: detect hidden memory hole size >? memblock: handle overlapped reserved memory region >? memblock: take a region intersecting an unknown region >? memblock: track memblock changed at early param >? memblock: recognize late freed size by checking PageReserved >? memblock: track kernel size on memsize >? memblock: print memsize summary information >? memblock: print kernel internal size >? memblock: support memsize reusable to consider as reusable > > drivers/of/fdt.c? ? ? ? ? ? |? 11 + > drivers/of/of_reserved_mem.c |? 12 +- > include/linux/memblock.h? ? |? 29 ++ > init/main.c? ? ? ? ? ? ? ? ? |? 13 +- > kernel/dma/contiguous.c? ? ? |? 9 +- > mm/Kconfig? ? ? ? ? ? ? ? ? |? 16 ++ > mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- > mm/mm_init.c? ? ? ? ? ? ? ? |? 6 +- > mm/page_alloc.c? ? ? ? ? ? ? |? 10 +- > 9 files changed, 597 insertions(+), 11 deletions(-) > >-- >2.25.1 Hello Mike 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. This helps us to communitcate well, to easily detect changes or just to see differences. Jaewon Kim
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. > > > >Here's an example > > > >$ cat debugfs/memblock/memsize > > > >0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma > >0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx > >... > >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown > >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx > >0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx > > > >Reserved? ? : 1223856 KB > > .kernel? ? :? 275208 KB > >? .text? ? :? 16576 KB > >? .rwdata? :? ? 1963 KB > >? .rodata? :? 11920 KB > >? .bss? ? ? :? ? 2450 KB > >? .memmap? :? 186368 KB > >? .etc? ? ? :? 55933 KB > > .unusable? :? 948648 KB > >System? ? ? : 11359056 KB > > .common? ? : 10306384 KB > > .reusable? : 1052672 KB > >Total? ? ? : 12582912 KB ( 12288.00 MB ) > > > >Jaewon Kim (10): > >? memblock: introduce memsize showing reserved memory > >? memblock: detect hidden memory hole size > >? memblock: handle overlapped reserved memory region > >? memblock: take a region intersecting an unknown region > >? memblock: track memblock changed at early param > >? memblock: recognize late freed size by checking PageReserved > >? memblock: track kernel size on memsize > >? memblock: print memsize summary information > >? memblock: print kernel internal size > >? memblock: support memsize reusable to consider as reusable > > > > drivers/of/fdt.c? ? ? ? ? ? |? 11 + > > drivers/of/of_reserved_mem.c |? 12 +- > > include/linux/memblock.h? ? |? 29 ++ > > init/main.c? ? ? ? ? ? ? ? ? |? 13 +- > > kernel/dma/contiguous.c? ? ? |? 9 +- > > mm/Kconfig? ? ? ? ? ? ? ? ? |? 16 ++ > > mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- > > mm/mm_init.c? ? ? ? ? ? ? ? |? 6 +- > > mm/page_alloc.c? ? ? ? ? ? ? |? 10 +- > > 9 files changed, 597 insertions(+), 11 deletions(-) > > > >-- > >2.25.1 > > Hello Mike > > 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? > This helps us to communitcate well, to easily detect changes or just to see differences. > > Jaewon Kim >
>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. >> > >> >Here's an example >> > >> >$ cat debugfs/memblock/memsize >> > >> >0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma >> >0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx >> >... >> >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >> >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >> >0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx >> > >> >Reserved? ? : 1223856 KB >> > .kernel? ? :? 275208 KB >> >? .text? ? :? 16576 KB >> >? .rwdata? :? ? 1963 KB >> >? .rodata? :? 11920 KB >> >? .bss? ? ? :? ? 2450 KB >> >? .memmap? :? 186368 KB >> >? .etc? ? ? :? 55933 KB >> > .unusable? :? 948648 KB >> >System? ? ? : 11359056 KB >> > .common? ? : 10306384 KB >> > .reusable? : 1052672 KB >> >Total? ? ? : 12582912 KB ( 12288.00 MB ) >> > >> >Jaewon Kim (10): >> >? memblock: introduce memsize showing reserved memory >> >? memblock: detect hidden memory hole size >> >? memblock: handle overlapped reserved memory region >> >? memblock: take a region intersecting an unknown region >> >? memblock: track memblock changed at early param >> >? memblock: recognize late freed size by checking PageReserved >> >? memblock: track kernel size on memsize >> >? memblock: print memsize summary information >> >? memblock: print kernel internal size >> >? memblock: support memsize reusable to consider as reusable >> > >> > drivers/of/fdt.c? ? ? ? ? ? |? 11 + >> > drivers/of/of_reserved_mem.c |? 12 +- >> > include/linux/memblock.h? ? |? 29 ++ >> > init/main.c? ? ? ? ? ? ? ? ? |? 13 +- >> > kernel/dma/contiguous.c? ? ? |? 9 +- >> > mm/Kconfig? ? ? ? ? ? ? ? ? |? 16 ++ >> > mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- >> > mm/mm_init.c? ? ? ? ? ? ? ? |? 6 +- >> > mm/page_alloc.c? ? ? ? ? ? ? |? 10 +- >> > 9 files changed, 597 insertions(+), 11 deletions(-) >> > >> >-- >> >2.25.1 >> >> Hello Mike >> >> 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. > >> This helps us to communitcate well, to easily detect changes or just to see differences. >> >> Jaewon Kim >> > >-- >Sincerely yours, >Mike.
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. >>> > >>> >Here's an example >>> > >>> >$ cat debugfs/memblock/memsize >>> > >>> >0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma >>> >0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx >>> >... >>> >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >>> >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >>> >0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx >>> > >>> >Reserved? ? : 1223856 KB >>> > .kernel? ? :? 275208 KB >>> >? .text? ? :? 16576 KB >>> >? .rwdata? :? ? 1963 KB >>> >? .rodata? :? 11920 KB >>> >? .bss? ? ? :? ? 2450 KB >>> >? .memmap? :? 186368 KB >>> >? .etc? ? ? :? 55933 KB >>> > .unusable? :? 948648 KB >>> >System? ? ? : 11359056 KB >>> > .common? ? : 10306384 KB >>> > .reusable? : 1052672 KB >>> >Total? ? ? : 12582912 KB ( 12288.00 MB ) >>> > >>> >Jaewon Kim (10): >>> >? memblock: introduce memsize showing reserved memory >>> >? memblock: detect hidden memory hole size >>> >? memblock: handle overlapped reserved memory region >>> >? memblock: take a region intersecting an unknown region >>> >? memblock: track memblock changed at early param >>> >? memblock: recognize late freed size by checking PageReserved >>> >? memblock: track kernel size on memsize >>> >? memblock: print memsize summary information >>> >? memblock: print kernel internal size >>> >? memblock: support memsize reusable to consider as reusable >>> > >>> > drivers/of/fdt.c? ? ? ? ? ? |? 11 + >>> > drivers/of/of_reserved_mem.c |? 12 +- >>> > include/linux/memblock.h? ? |? 29 ++ >>> > init/main.c? ? ? ? ? ? ? ? ? |? 13 +- >>> > kernel/dma/contiguous.c? ? ? |? 9 +- >>> > mm/Kconfig? ? ? ? ? ? ? ? ? |? 16 ++ >>> > mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- >>> > mm/mm_init.c? ? ? ? ? ? ? ? |? 6 +- >>> > mm/page_alloc.c? ? ? ? ? ? ? |? 10 +- >>> > 9 files changed, 597 insertions(+), 11 deletions(-) >>> > >>> >-- >>> >2.25.1 >>> >>> Hello Mike >>> >>> 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. Would you mind showing which information matters to you most in the following example log message? What you expect to see and helps you on locating problem? 0x0000000000000000-0x0000000000000000 0x02000000 ( 32768 KB ) map reusable linux,cma 0x0000000000000000-0x0000000000000000 0x01000000 ( 16384 KB ) map reusable vxxxxx .. 0x0000000000000000-0x0000000000000000 0x004e0000 ( 4992 KB ) nomap unusable unknown 0x0000000000000000-0x0000000000000000 0x00400000 ( 4096 KB ) nomap unusable cxxxxx 0x0000000000000000-0x0000000000000000 0x00e00000 ( 14336 KB ) nomap unusable gxxxxx Reserved : 1223856 KB .kernel : 275208 KB .text : 16576 KB .rwdata : 1963 KB .rodata : 11920 KB .bss : 2450 KB .memmap : 186368 KB .etc : 55933 KB .unusable : 948648 KB System : 11359056 KB .common : 10306384 KB .reusable : 1052672 KB Total : 12582912 KB ( 12288.00 MB ) >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. You mean we may reserve memory in memblock.reserved, but still have it freed to system? This sounds a bug to me. >I think a simple debug interface is needed to easily communicate with others or compare different SW releases. > >> >>> This helps us to communitcate well, to easily detect changes or just to see differences. >>> >>> Jaewon Kim >>> >> >>-- >>Sincerely yours, >>Mike. > >
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. >> >>Here's an example >> >>$ cat debugfs/memblock/memsize >> >>0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma >>0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx >>... >>0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >>0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >>0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx >> >>Reserved? ? : 1223856 KB >> .kernel? ? :? 275208 KB >>? .text? ? :? 16576 KB >>? .rwdata? :? ? 1963 KB >>? .rodata? :? 11920 KB >>? .bss? ? ? :? ? 2450 KB >>? .memmap? :? 186368 KB >>? .etc? ? ? :? 55933 KB >> .unusable? :? 948648 KB >>System? ? ? : 11359056 KB >> .common? ? : 10306384 KB >> .reusable? : 1052672 KB >>Total? ? ? : 12582912 KB ( 12288.00 MB ) >> >>Jaewon Kim (10): >>? memblock: introduce memsize showing reserved memory >>? memblock: detect hidden memory hole size >>? memblock: handle overlapped reserved memory region >>? memblock: take a region intersecting an unknown region >>? memblock: track memblock changed at early param >>? memblock: recognize late freed size by checking PageReserved >>? memblock: track kernel size on memsize >>? memblock: print memsize summary information >>? memblock: print kernel internal size >>? memblock: support memsize reusable to consider as reusable >> >> drivers/of/fdt.c? ? ? ? ? ? |? 11 + >> drivers/of/of_reserved_mem.c |? 12 +- >> include/linux/memblock.h? ? |? 29 ++ >> init/main.c? ? ? ? ? ? ? ? ? |? 13 +- >> kernel/dma/contiguous.c? ? ? |? 9 +- >> mm/Kconfig? ? ? ? ? ? ? ? ? |? 16 ++ >> mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- >> mm/mm_init.c? ? ? ? ? ? ? ? |? 6 +- >> mm/page_allocc? ? ? ? ? ? ? |? 10 +- >> 9 files changed, 597 insertions(+), 11 deletions(-) >> >>-- >>2.25.1 > >Hello Mike > >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. > Maybe you can show the log difference, so that we can see how it helps you. >This helps us to communitcate well, to easily detect changes or just to see differences. > >Jaewon Kim >
>Sender : Wei Yang <richard.weiyang@gmail.com> >Date : 2024-05-22 17:16 (GMT+9) >Title : Re: (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory >? >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. >>>> > >>>> >Here's an example >>>> > >>>> >$ cat debugfs/memblock/memsize >>>> > >>>> >0x0000000000000000-0x0000000000000000 0x02000000 (?? 32768 KB )?? map reusable linux,cma >>>> >0x0000000000000000-0x0000000000000000 0x01000000 (?? 16384 KB )?? map reusable vxxxxx >>>> >... >>>> >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >>>> >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >>>> >0x0000000000000000-0x0000000000000000 0x00e00000 (?? 14336 KB ) nomap unusable gxxxxx >>>> > >>>> >Reserved? ? : 1223856 KB >>>> > .kernel? ? :? 275208 KB >>>> >? .text? ?? :?? 16576 KB >>>> >? .rwdata?? :? ? 1963 KB >>>> >? .rodata?? :?? 11920 KB >>>> >? .bss? ? ? :? ? 2450 KB >>>> >? .memmap?? :? 186368 KB >>>> >? .etc? ? ? :?? 55933 KB >>>> > .unusable? :? 948648 KB >>>> >System? ? ? : 11359056 KB >>>> > .common? ? : 10306384 KB >>>> > .reusable? : 1052672 KB >>>> >Total? ? ?? : 12582912 KB ( 12288.00 MB ) >>>> > >>>> >Jaewon Kim (10): >>>> >? memblock: introduce memsize showing reserved memory >>>> >? memblock: detect hidden memory hole size >>>> >? memblock: handle overlapped reserved memory region >>>> >? memblock: take a region intersecting an unknown region >>>> >? memblock: track memblock changed at early param >>>> >? memblock: recognize late freed size by checking PageReserved >>>> >? memblock: track kernel size on memsize >>>> >? memblock: print memsize summary information >>>> >? memblock: print kernel internal size >>>> >? memblock: support memsize reusable to consider as reusable >>>> > >>>> > drivers/of/fdt.c? ? ? ? ? ?? |? 11 + >>>> > drivers/of/of_reserved_mem.c |? 12 +- >>>> > include/linux/memblock.h? ?? |? 29 ++ >>>> > init/main.c? ? ? ? ? ? ? ? ? |? 13 +- >>>> > kernel/dma/contiguous.c? ? ? |?? 9 +- >>>> > mm/Kconfig? ? ? ? ? ? ? ? ?? |? 16 ++ >>>> > mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++- >>>> > mm/mm_init.c? ? ? ? ? ? ? ?? |?? 6 +- >>>> > mm/page_alloc.c? ? ? ? ? ? ? |? 10 +- >>>> > 9 files changed, 597 insertions(+), 11 deletions(-) >>>> > >>>> >-- >>>> >2.25.1 >>>> >>>> Hello Mike >>>> >>>> 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. Hi > Maybe you can show the log difference, so that we can see how it helps you. For your new email, could you elaborate the difference you meant? Do you mean difference between existing debugfs membock interfaces and the one I introdued here? >>> >>>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. > >Would you mind showing which information matters to you most in the following >example log message? What you expect to see and helps you on locating problem? > >0x0000000000000000-0x0000000000000000 0x02000000 (? 32768 KB )? map reusable linux,cma >0x0000000000000000-0x0000000000000000 0x01000000 (? 16384 KB )? map reusable vxxxxx >.. >0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown >0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx >0x0000000000000000-0x0000000000000000 0x00e00000 (? 14336 KB ) nomap unusable gxxxxx > >Reserved? ? : 1223856 KB > .kernel? ? :? 275208 KB >? .text? ? :? 16576 KB >? .rwdata? :? ? 1963 KB >? .rodata? :? 11920 KB >? .bss? ? ? :? ? 2450 KB >? .memmap? :? 186368 KB >? .etc? ? ? :? 55933 KB > .unusable? :? 948648 KB >System? ? ? : 11359056 KB > .common? ? : 10306384 KB > .reusable? : 1052672 KB >Total? ? ? : 12582912 KB ( 12288.00 MB ) > I need all those information actually. address, size, map/nomap, reusable/unusable, name. For me it was very helpful to rearrange the memory regions as it shows clearly. The address could be seen after allowing it through /proc/sys/kernel/kptr_restrict. Kernel size information is also helpful to me. The memmap size for struct pages could be increased according to DRAM memory size. By rearranging the reserved regions to be packed we can save memmap memory, then we can see the results easily from this. We can compare other text, ro, rw, etc so that we can find which part of kernel has changed. >>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. > >You mean we may reserve memory in memblock.reserved, but still have it freed >to system? This sounds a bug to me. I mean something like free_reserved_area. The reserved free pages would be free to system buddy allocator directly without reporting it to memblock. > >>I think a simple debug interface is needed to easily communicate with others or compare different SW releases. >> >>> >>>> This helps us to communitcate well, to easily detect changes or just to see differences. >>>> >>>> Jaewon Kim >>>> >>> >>>-- >>>Sincerely yours, >>>Mike. >> >> > >-- >Wei Yang >Help you, Help me >
On Wed, May 22, 2024 at 05:47:38PM +0900, Jaewon Kim wrote: [...] > >Hi > >> Maybe you can show the log difference, so that we can see how it helps you. > >For your new email, could you elaborate the difference you meant? >Do you mean difference between existing debugfs membock interfaces and the one I introdued here? > You mentioned the difference between kernel version helps you locate the problem. That is the difference of your new debugfs.
>[...] >> >>Hi >> >>> Maybe you can show the log difference, so that we can see how it helps you. >> >>For your new email, could you elaborate the difference you meant? >>Do you mean difference between existing debugfs membock interfaces and the one I introdued here? >> > >You mentioned the difference between kernel version helps you locate the >problem. That is the difference of your new debugfs. Correct. Actually we get many SW release from chipset vendors. Even though their kernel version is same, the reserved memory status varies. So we can easily compare them. BR > > >-- >Wei Yang >Help you, Help me
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.
>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. 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.
On Thu, 23 May 2024 at 20:06, Mike Rapoport <rppt@kernel.org> 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. Something similar, we have already proposed almost 10 years ago for memblock. That time I realised some of these reserved memory break-up becomes useful and handy when we are gathering reserved memory stats on a small embedded device where every bit of memory reserved is important and being questioned. You can get some information about Kernel reserved from dmesg | grep -i Memory (including the kernel init, text, data) and the cma-reserved as well. Here the cma-reserved was added by me. You can also get these Kernel reserved size info from vmlinux. size -t vmlinux
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
>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@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? 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.
>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@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? 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.
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@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? > > 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.
On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote: ><!DOCTYPE html> ><html> ><head> ... Would you mind sending it in pure text again?
(Sorry I might forget to change to be plain text) 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 On Wed, May 29, 2024 at 8:35 PM Wei Yang <richard.weiyang@gmail.com> wrote: > > On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote: > ><!DOCTYPE html> > ><html> > ><head> > ... > > Would you mind sending it in pure text again? > > -- > Wei Yang > Help you, Help me
On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >(Sorry I might forget to change to be plain text) > >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 memblock/memory only shows ranges put in "memory". memblock/reserved shows ranges put in "reserved". If we just put them in "reserved", it will not displayed in "memory". >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 > I guess those ranges are only put into "reserved"? Have those ranges put in "memory"? Would you mind point the code where those messages are printed? >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 > >On Wed, May 29, 2024 at 8:35 PM Wei Yang <richard.weiyang@gmail.com> wrote: >> >> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote: >> ><!DOCTYPE html> >> ><html> >> ><head> >> ... >> >> Would you mind sending it in pure text again? >> >> -- >> Wei Yang >> Help you, Help me
>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>(Sorry I might forget to change to be plain text) >> >>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 > >memblock/memory only shows ranges put in "memory". >memblock/reserved shows ranges put in "reserved". > >If we just put them in "reserved", it will not displayed in "memory". > Hi Let me explain more. In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. # xxd -g 8 /proc/device-tree/memory/reg 00000000: 0000000081960000 00000000000a0000 ................ 00000010: 0000000081a40000 00000000001c0000 ................ # cat sys/kernel/debug/memblock/memory 0: 0x0000000081960000..0x00000000819fffff 0 NONE 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE # cat sys/kernel/debug/memblock/reserved 0: 0x0000000082800000..0x00000000847fffff 0 NONE The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. (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 DDD So a smart parser should combine the krenel log and the memblock/memory log. In my memsize feature shows it like this though. 0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown BR >>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 >> > >I guess those ranges are only put into "reserved"? Have those ranges put in >"memory"? Would you mind point the code where those messages are printed? > >>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 >> >>On Wed, May 29, 2024 at 8:35?PM Wei Yang <richard.weiyang@gmail.com> wrote: >>> >>> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote: >>> ><!DOCTYPE html> >>> ><html> >>> ><head> >>> ... >>> >>> Would you mind sending it in pure text again? >>> >>> -- >>> Wei Yang >>> Help you, Help me > >-- >Wei Yang >Help you, Help me
On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote: >>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>>(Sorry I might forget to change to be plain text) >>> >>>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 >> >>memblock/memory only shows ranges put in "memory". >>memblock/reserved shows ranges put in "reserved". >> >>If we just put them in "reserved", it will not displayed in "memory". > >Hi >Let me explain more. > >In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. > ># xxd -g 8 /proc/device-tree/memory/reg >00000000: 0000000081960000 00000000000a0000 ................ >00000010: 0000000081a40000 00000000001c0000 ................ > ># cat sys/kernel/debug/memblock/memory > 0: 0x0000000081960000..0x00000000819fffff 0 NONE > 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE > ># cat sys/kernel/debug/memblock/reserved > 0: 0x0000000082800000..0x00000000847fffff 0 NONE > >The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. > >(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 DDD > This looks not printed by memblock_reserve(), right? It is printed by your own driver? >So a smart parser should combine the krenel log and the memblock/memory log. > >In my memsize feature shows it like this though. > >0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown > >BR > I am sorry, I still not catch your point. Let me try to understand your message. You mentioned several regions, let me put them in order. (1) 0x0000000080000000..0x0000000080dfffff printed by driver (2) 0x0000000080e00000..0x00000000811fffff printed by driver (3) 0x0000000081200000..0x00000000813fffff printed by driver (4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs (5) 0x0000000081960000..0x00000000819fffff listed in reg/memory (6) 0x0000000081a00000..0x0000000081a3ffff printed by driver (7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory (8) 0x0000000082800000..0x00000000847fffff listed in reserved If you just want information for region (4), sound we can do it in user-space? BTW, are region 1, 2, 3, 6, reserved in membock?
>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote: >>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>>>(Sorry I might forget to change to be plain text) >>>> >>>>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 >>> >>>memblock/memory only shows ranges put in "memory". >>>memblock/reserved shows ranges put in "reserved". >>> >>>If we just put them in "reserved", it will not displayed in "memory". >> >>Hi >>Let me explain more. >> >>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. >> >># xxd -g 8 /proc/device-tree/memory/reg >>00000000: 0000000081960000 00000000000a0000 ................ >>00000010: 0000000081a40000 00000000001c0000 ................ >> >># cat sys/kernel/debug/memblock/memory >> 0: 0x0000000081960000..0x00000000819fffff 0 NONE >> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE >> >># cat sys/kernel/debug/memblock/reserved >> 0: 0x0000000082800000..0x00000000847fffff 0 NONE >> >>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. >> >>(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 DDD >> > >This looks not printed by memblock_reserve(), right? It is printed by your own >driver? AFAIK these log came from the commit below. aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot > >>So a smart parser should combine the krenel log and the memblock/memory log. >> >>In my memsize feature shows it like this though. >> >>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown >> >>BR >> > >I am sorry, I still not catch your point. Let me try to understand your message. > >You mentioned several regions, let me put them in order. > >(1) 0x0000000080000000..0x0000000080dfffff printed by driver >(2) 0x0000000080e00000..0x00000000811fffff printed by driver >(3) 0x0000000081200000..0x00000000813fffff printed by driver >(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs >(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory >(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver >(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory >(8) 0x0000000082800000..0x00000000847fffff listed in reserved > >If you just want information for region (4), sound we can do it in user-space? > >BTW, are region 1, 2, 3, 6, reserved in membock? Yes correct, I though (4) case could be shown to easily catch these hidden regions. As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as they are defined in kernel device tree. > >-- >Wei Yang >Help you, Help me
On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote: >>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote: >>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>>>>(Sorry I might forget to change to be plain text) >>>>> >>>>>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 >>>> >>>>memblock/memory only shows ranges put in "memory". >>>>memblock/reserved shows ranges put in "reserved". >>>> >>>>If we just put them in "reserved", it will not displayed in "memory". >>> >>>Hi >>>Let me explain more. >>> >>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. >>> >>># xxd -g 8 /proc/device-tree/memory/reg >>>00000000: 0000000081960000 00000000000a0000 ................ >>>00000010: 0000000081a40000 00000000001c0000 ................ >>> >>># cat sys/kernel/debug/memblock/memory >>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE >>> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE >>> >>># cat sys/kernel/debug/memblock/reserved >>> 0: 0x0000000082800000..0x00000000847fffff 0 NONE >>> >>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. >>> >>>(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 DDD >>> >> >>This looks not printed by memblock_reserve(), right? It is printed by your own >>driver? > >AFAIK these log came from the commit below. >aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot > >> >>>So a smart parser should combine the krenel log and the memblock/memory log. >>> >>>In my memsize feature shows it like this though. >>> >>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown >>> >>>BR >>> >> >>I am sorry, I still not catch your point. Let me try to understand your message. >> >>You mentioned several regions, let me put them in order. >> >>(1) 0x0000000080000000..0x0000000080dfffff printed by driver >>(2) 0x0000000080e00000..0x00000000811fffff printed by driver >>(3) 0x0000000081200000..0x00000000813fffff printed by driver >>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs >>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory >>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver >>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory >>(8) 0x0000000082800000..0x00000000847fffff listed in reserved >> >>If you just want information for region (4), sound we can do it in user-space? >> >>BTW, are region 1, 2, 3, 6, reserved in membock? > >Yes correct, I though (4) case could be shown to easily catch these hidden regions. >As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as >they are defined in kernel device tree. > As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those information is not shown in memblock/reserve. I am afraid the proper way is to let memblock know those ranges. Sounds "of" driver doesn't tell memblock about these. > >> >>-- >>Wei Yang >>Help you, Help me
>On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote: >>>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote: >>>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>>>>>(Sorry I might forget to change to be plain text) >>>>>> >>>>>>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 >>>>> >>>>>memblock/memory only shows ranges put in "memory". >>>>>memblock/reserved shows ranges put in "reserved". >>>>> >>>>>If we just put them in "reserved", it will not displayed in "memory". >>>> >>>>Hi >>>>Let me explain more. >>>> >>>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. >>>> >>>># xxd -g 8 /proc/device-tree/memory/reg >>>>00000000: 0000000081960000 00000000000a0000 ................ >>>>00000010: 0000000081a40000 00000000001c0000 ................ >>>> >>>># cat sys/kernel/debug/memblock/memory >>>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE >>>> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE >>>> >>>># cat sys/kernel/debug/memblock/reserved >>>> 0: 0x0000000082800000..0x00000000847fffff 0 NONE >>>> >>>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. >>>> >>>>(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 DDD >>>> >>> >>>This looks not printed by memblock_reserve(), right? It is printed by your own >>>driver? >> >>AFAIK these log came from the commit below. >>aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot >> >>> >>>>So a smart parser should combine the krenel log and the memblock/memory log. >>>> >>>>In my memsize feature shows it like this though. >>>> >>>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown >>>> >>>>BR >>>> >>> >>>I am sorry, I still not catch your point. Let me try to understand your message. >>> >>>You mentioned several regions, let me put them in order. >>> >>>(1) 0x0000000080000000..0x0000000080dfffff printed by driver >>>(2) 0x0000000080e00000..0x00000000811fffff printed by driver >>>(3) 0x0000000081200000..0x00000000813fffff printed by driver >>>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs >>>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory >>>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver >>>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory >>>(8) 0x0000000082800000..0x00000000847fffff listed in reserved >>> >>>If you just want information for region (4), sound we can do it in user-space? >>> >>>BTW, are region 1, 2, 3, 6, reserved in membock? >> >>Yes correct, I though (4) case could be shown to easily catch these hidden regions. >>As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as >>they are defined in kernel device tree. >> > >As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those >information is not shown in memblock/reserve. > >I am afraid the proper way is to let memblock know those ranges. Sounds "of" >driver doesn't tell memblock about these. > Yes that is the reason why I added some code to 'of' driver, too. As I said, if we don't change 'of' driver and memblck, we need a smart parser looking into kernel log and memblock info, and understand these special cases. BR >> >>> >>>-- >>>Wei Yang >>>Help you, Help me >