| Message ID | 20220324070158.22969-1-jaewon31.kim@samsung.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | memblock: introduce memsize showing reserved memory | expand |
Hi, On Thu, Mar 24, 2022 at 04:01:50PM +0900, Jaewon Kim wrote: > 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 > 0x0f9000000-0x0fb000000 0x02000000 ( 32768 KB ) map reusable linux,cma > 0x0b1900000-0x0b1b00000 0x00200000 ( 2048 KB ) nomap unusable test1 > 0x0b0200000-0x0b0400000 0x00200000 ( 2048 KB ) map unusable test2 > (snipped) > > Reserved : 746924 KB > .kernel : 137027 KB > .text : 28158 KB > .rwdata : 3238 KB > .rodata : 13468 KB > .bss : 12570 KB > .etc : 79593 KB > .unusable : 609897 KB > System : 3447380 KB > .common : 3152468 KB > .reusable : 294912 KB > Total : 4194304 KB ( 4096.00 MB ) Most of this information information is already available at various places, like the existing memblock debugfs, /proc/iomem and DT sysfs. I don't see why we need yet another debugfs file to expose it. > Jaewon Kim (8): > memblock: introduce memsize showing reserved memory > memblock: detect hidden memory hole size > memblock: handle overlapped reserved memory region > memblock: track memblock changed at early param > memblock: track kernel size on memsize > memblock: recognize late free by checking PageReserved > memblock: print memsize summary information > memblock: print kernel internal size > > drivers/of/fdt.c | 10 + > drivers/of/of_reserved_mem.c | 7 +- > include/linux/memblock.h | 21 ++ > include/linux/mm.h | 3 + > init/main.c | 13 +- > kernel/dma/contiguous.c | 9 +- > mm/Kconfig | 7 + > mm/memblock.c | 434 ++++++++++++++++++++++++++++++++++- > mm/page_alloc.c | 15 +- > 9 files changed, 506 insertions(+), 13 deletions(-) > > -- > 2.17.1 >
> > >--------- Original Message --------- >Sender : Mike Rapoport <rppt@kernel.org> >Date : 2022-03-25 16:46 (GMT+9) >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > >Hi, > >On Thu, Mar 24, 2022 at 04:01:50PM +0900, Jaewon Kim wrote: >> 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 >> 0x0f9000000-0x0fb000000 0x02000000 ( 32768 KB ) map reusable linux,cma >> 0x0b1900000-0x0b1b00000 0x00200000 ( 2048 KB ) nomap unusable test1 >> 0x0b0200000-0x0b0400000 0x00200000 ( 2048 KB ) map unusable test2 >> (snipped) >> >> Reserved : 746924 KB >> .kernel : 137027 KB >> .text : 28158 KB >> .rwdata : 3238 KB >> .rodata : 13468 KB >> .bss : 12570 KB >> .etc : 79593 KB >> .unusable : 609897 KB >> System : 3447380 KB >> .common : 3152468 KB >> .reusable : 294912 KB >> Total : 4194304 KB ( 4096.00 MB ) > >Most of this information information is already available at various >places, like the existing memblock debugfs, /proc/iomem and DT sysfs. > >I don't see why we need yet another debugfs file to expose it. Hi. Thank you for your reply. I don't think existing memblock debugfs or /proc/iomem shows information I want. They don't show name and actually allocated address and size. And it does not handle pages freed to buddy allocator after boot. And which DT sysfs do you mean? If it is /proc/device-tree/reserved-memory, it shows name and size, but it does not show address for only size defined regions. It does not recognize the freed pages, either. Especially I'd like to create a node showing all reserved memory status, their total size is same as the physical memory size. This was very useful when I compare reserved memory and kernel init time memory between different chipsets, or between different sw release versions. Thank you Jaewon Kim > >> Jaewon Kim (8): >> memblock: introduce memsize showing reserved memory >> memblock: detect hidden memory hole size >> memblock: handle overlapped reserved memory region >> memblock: track memblock changed at early param >> memblock: track kernel size on memsize >> memblock: recognize late free by checking PageReserved >> memblock: print memsize summary information >> memblock: print kernel internal size >> >> drivers/of/fdt.c | 10 + >> drivers/of/of_reserved_mem.c | 7 +- >> include/linux/memblock.h | 21 ++ >> include/linux/mm.h | 3 + >> init/main.c | 13 +- >> kernel/dma/contiguous.c | 9 +- >> mm/Kconfig | 7 + >> mm/memblock.c | 434 ++++++++++++++++++++++++++++++++++- >> mm/page_alloc.c | 15 +- >> 9 files changed, 506 insertions(+), 13 deletions(-) >> >> -- >> 2.17.1 >> > >-- >Sincerely yours, >Mike. >
Hi, On Fri, Mar 25, 2022 at 05:38:46PM +0900, Jaewon Kim wrote: > >--------- Original Message --------- > >Sender : Mike Rapoport <rppt@kernel.org> > >Date : 2022-03-25 16:46 (GMT+9) > >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > > > >Hi, > > > >On Thu, Mar 24, 2022 at 04:01:50PM +0900, Jaewon Kim wrote: > >> 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 > >> 0x0f9000000-0x0fb000000 0x02000000 ( 32768 KB ) map reusable linux,cma > >> 0x0b1900000-0x0b1b00000 0x00200000 ( 2048 KB ) nomap unusable test1 > >> 0x0b0200000-0x0b0400000 0x00200000 ( 2048 KB ) map unusable test2 > >> (snipped) > >> > >> Reserved : 746924 KB > >> .kernel : 137027 KB > >> .text : 28158 KB > >> .rwdata : 3238 KB > >> .rodata : 13468 KB > >> .bss : 12570 KB > >> .etc : 79593 KB > >> .unusable : 609897 KB > >> System : 3447380 KB > >> .common : 3152468 KB > >> .reusable : 294912 KB > >> Total : 4194304 KB ( 4096.00 MB ) > > > >Most of this information information is already available at various > >places, like the existing memblock debugfs, /proc/iomem and DT sysfs. > > > >I don't see why we need yet another debugfs file to expose it. > > Hi. > Thank you for your reply. > > Especially I'd like to create a node showing all reserved memory status, their > total size is same as the physical memory size. This was very useful when I > compare reserved memory and kernel init time memory between different chipsets, > or between different sw release versions. I'm still not following. The reserved region sizes are available in the existing memblock debugfs. Why the names are important? What is the value of having names for *some* of the reserved regions? > Thank you > Jaewon Kim
> > >--------- Original Message --------- >Sender : Mike Rapoport <rppt@kernel.org> >Date : 2022-03-27 16:40 (GMT+9) >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > >Hi, > >On Fri, Mar 25, 2022 at 05:38:46PM +0900, Jaewon Kim wrote: > >> >--------- Original Message --------- >> >Sender : Mike Rapoport <rppt@kernel.org> >> >Date : 2022-03-25 16:46 (GMT+9) >> >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory >> > >> >Hi, >> > >> >On Thu, Mar 24, 2022 at 04:01:50PM +0900, Jaewon Kim wrote: >> >> 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 >> >> 0x0f9000000-0x0fb000000 0x02000000 ( 32768 KB ) map reusable linux,cma >> >> 0x0b1900000-0x0b1b00000 0x00200000 ( 2048 KB ) nomap unusable test1 >> >> 0x0b0200000-0x0b0400000 0x00200000 ( 2048 KB ) map unusable test2 >> >> (snipped) >> >> >> >> Reserved : 746924 KB >> >> .kernel : 137027 KB >> >> .text : 28158 KB >> >> .rwdata : 3238 KB >> >> .rodata : 13468 KB >> >> .bss : 12570 KB >> >> .etc : 79593 KB >> >> .unusable : 609897 KB >> >> System : 3447380 KB >> >> .common : 3152468 KB >> >> .reusable : 294912 KB >> >> Total : 4194304 KB ( 4096.00 MB ) >> > >> >Most of this information information is already available at various >> >places, like the existing memblock debugfs, /proc/iomem and DT sysfs. >> > >> >I don't see why we need yet another debugfs file to expose it. >> >> Hi. >> Thank you for your reply. >> >> I don't think existing memblock debugfs or /proc/iomem shows information I want. >> They don't show name and actually allocated address and size. And it does not >> handle pages freed to buddy allocator after boot. >> >> And which DT sysfs do you mean? If it is /proc/device-tree/reserved-memory, it >> shows name and size, but it does not show address for only size defined regions. >> It does not recognize the freed pages, either. >> >> Especially I'd like to create a node showing all reserved memory status, their >> total size is same as the physical memory size. This was very useful when I >> compare reserved memory and kernel init time memory between different chipsets, >> or between different sw release versions. > >I'm still not following. The reserved region sizes are available in the >existing memblock debugfs. >Why the names are important? What is the value of having names for *some* >of the reserved regions? Hi There are many memory regions in memblock debugfs memory/reserved, and some might be splited or merged with other region. Among regions in debugfs, we can't find the one we defined in device tree. Especially it is difficult to find the region we described size only without start address. On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure world, Audio, ETC. To support them, there are many reserved regions described in device tree. So the name is quite important to recognize a region. And with thename we can compare reserved memory map with other map. Additionally as I said, we need one simple knob to look overall reservecd memory status. Thank you Jaewon Kim > >> Thank you >> Jaewon Kim > >-- >Sincerely yours, >Mike. >
On Sun, Mar 27, 2022 at 10:53:47PM +0900, Jaewon Kim wrote: > > > >--------- Original Message --------- > >Sender : Mike Rapoport <rppt@kernel.org> > >Date : 2022-03-27 16:40 (GMT+9) > >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > > > > > >I'm still not following. The reserved region sizes are available in the > >existing memblock debugfs. > >Why the names are important? What is the value of having names for *some* > >of the reserved regions? > > Hi > > There are many memory regions in memblock debugfs memory/reserved, and some might > be splited or merged with other region. Among regions in debugfs, we can't find > the one we defined in device tree. Especially it is difficult to find the region we > described size only without start address. > > On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure > world, Audio, ETC. To support them, there are many reserved regions described in > device tree. So the name is quite important to recognize a region. And with thename > we can compare reserved memory map with other map. You still didn't describe your use case. What is the problem your patches are trying to solve? Why is it important to know what is the use of particular reserved region? 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". Does not sound convincing to me, sorry. > Thank you > Jaewon Kim
>> > >> >--------- Original Message --------- >> >Sender : Mike Rapoport <rppt@kernel.org> >> >Date : 2022-03-27 16:40 (GMT+9) >> >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory >> > >> > >> >I'm still not following. The reserved region sizes are available in the >> >existing memblock debugfs. >> >Why the names are important? What is the value of having names for *some* >> >of the reserved regions? >> >> Hi >> >> There are many memory regions in memblock debugfs memory/reserved, and some might >> be splited or merged with other region. Among regions in debugfs, we can't find >> the one we defined in device tree. Especially it is difficult to find the region we >> described size only without start address. >> >> On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure >> world, Audio, ETC. To support them, there are many reserved regions described in >> device tree. So the name is quite important to recognize a region. And with thename >> we can compare reserved memory map with other map. > >You still didn't describe your use case. What is the problem your patches >are trying to solve? Why is it important to know what is the use of particular >reserved region? > >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". > >Does not sound convincing to me, sorry. As I said serveral times, I want a simple knob showing all reserved memory status. The current debugfs, device tree do not show all those information I want. I think you also know that. i.e. late freed pages, splited or merged memblock, address defined at boot time, kernel size, ETC. Anyway I think I touched too many points to do this. Let me drop this. > >> Thank you >> Jaewon Kim > >-- >Sincerely yours, >Mike. >
Hi, On Tue, Mar 29, 2022 at 11:46:20AM +0900, Jaewon Kim wrote: > >> > > >> >I'm still not following. The reserved region sizes are available in the > >> >existing memblock debugfs. > >> >Why the names are important? What is the value of having names for *some* > >> >of the reserved regions? > >> > >> Hi > >> > >> There are many memory regions in memblock debugfs memory/reserved, and some might > >> be splited or merged with other region. Among regions in debugfs, we can't find > >> the one we defined in device tree. Especially it is difficult to find the region we > >> described size only without start address. > >> > >> On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure > >> world, Audio, ETC. To support them, there are many reserved regions described in > >> device tree. So the name is quite important to recognize a region. And with thename > >> we can compare reserved memory map with other map. > > > >You still didn't describe your use case. What is the problem your patches > >are trying to solve? Why is it important to know what is the use of particular > >reserved region? > > > >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". > > > >Does not sound convincing to me, sorry. > > As I said serveral times, I want a simple knob showing all reserved > memory status. The current debugfs, device tree do not show all those > information I want. I think you also know that. i.e. late freed pages, > splited or merged memblock, address defined at boot time, kernel size, > ETC. I know that there is not much information about reserved memory exposed and I understand *what* are you trying to achieve. But you never provided details about *why* you want this information exposed. 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.
>Hi, > >On Tue, Mar 29, 2022 at 11:46:20AM +0900, Jaewon Kim wrote: >> >> > >> >> >I'm still not following. The reserved region sizes are available in the >> >> >existing memblock debugfs. >> >> >Why the names are important? What is the value of having names for *some* >> >> >of the reserved regions? >> >> >> >> Hi >> >> >> >> There are many memory regions in memblock debugfs memory/reserved, and some might >> >> be splited or merged with other region. Among regions in debugfs, we can't find >> >> the one we defined in device tree. Especially it is difficult to find the region we >> >> described size only without start address. >> >> >> >> On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure >> >> world, Audio, ETC. To support them, there are many reserved regions described in >> >> device tree. So the name is quite important to recognize a region. And with thename >> >> we can compare reserved memory map with other map. >> > >> >You still didn't describe your use case. What is the problem your patches >> >are trying to solve? Why is it important to know what is the use of particular >> >reserved region? >> > >> >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". >> > >> >Does not sound convincing to me, sorry. >> >> As I said serveral times, I want a simple knob showing all reserved >> memory status. The current debugfs, device tree do not show all those >> information I want. I think you also know that. i.e. late freed pages, >> splited or merged memblock, address defined at boot time, kernel size, >> ETC. > >I know that there is not much information about reserved memory exposed and >I understand *what* are you trying to achieve. But you never provided >details about *why* you want this information exposed. > >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. > I think the "what" is same as "why". I want to look at all reservced memory status simply in a knob. I also want to make in more simple and localized way, but there seems be several ways to change reserved memory such as cmdline way, freeing after boot, etc. I wanted to cover all those things. That's OK. I hope someone later to try this again to show all the info. >-- >Sincerely yours, >Mike.