| Message ID | 20211119075844.2902592-1-calvinzhang.cool@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | of: remove reserved regions count restriction | expand |
On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote: > The count of reserved regions in /reserved-memory was limited because > the struct reserved_mem array was defined statically. This series sorts > out reserved memory code and allocates that array from early allocator. > > Note: reserved region with fixed location must be reserved before any > memory allocation. While struct reserved_mem array should be allocated > after allocator is activated. We make early_init_fdt_scan_reserved_mem() > do reservation only and add another call to initialize reserved memory. > So arch code have to change for it. I think much simpler would be to use the same constant for sizing memblock.reserved and reserved_mem arrays. If there is too much reserved regions in the device tree, reserving them in memblock will fail anyway because memblock also starts with static array for memblock.reserved, so doing one pass with memblock_reserve() and another to set up reserved_mem wouldn't help anyway. > I'm only familiar with arm and arm64 architectures. Approvals from arch > maintainers are required. Thank you all. > > Calvin Zhang (2): > of: Sort reserved_mem related code > of: reserved_mem: Remove reserved regions count restriction > > arch/arc/mm/init.c | 3 + > arch/arm/kernel/setup.c | 2 + > arch/arm64/kernel/setup.c | 3 + > arch/csky/kernel/setup.c | 3 + > arch/h8300/kernel/setup.c | 2 + > arch/mips/kernel/setup.c | 3 + > arch/nds32/kernel/setup.c | 3 + > arch/nios2/kernel/setup.c | 2 + > arch/openrisc/kernel/setup.c | 3 + > arch/powerpc/kernel/setup-common.c | 3 + > arch/riscv/kernel/setup.c | 2 + > arch/sh/kernel/setup.c | 3 + > arch/xtensa/kernel/setup.c | 2 + > drivers/of/fdt.c | 107 +--------------- > drivers/of/of_private.h | 12 +- > drivers/of/of_reserved_mem.c | 189 ++++++++++++++++++++++++----- > include/linux/of_reserved_mem.h | 4 + > 17 files changed, 207 insertions(+), 139 deletions(-) > > -- > 2.30.2 >
On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote: >On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote: >> The count of reserved regions in /reserved-memory was limited because >> the struct reserved_mem array was defined statically. This series sorts >> out reserved memory code and allocates that array from early allocator. >> >> Note: reserved region with fixed location must be reserved before any >> memory allocation. While struct reserved_mem array should be allocated >> after allocator is activated. We make early_init_fdt_scan_reserved_mem() >> do reservation only and add another call to initialize reserved memory. >> So arch code have to change for it. > >I think much simpler would be to use the same constant for sizing >memblock.reserved and reserved_mem arrays. > >If there is too much reserved regions in the device tree, reserving them in >memblock will fail anyway because memblock also starts with static array >for memblock.reserved, so doing one pass with memblock_reserve() and >another to set up reserved_mem wouldn't help anyway. Yes. This happens only if there are two many fixed reserved regions. memblock.reserved can be resized after paging. I also find another problem. Initializing dynamic reservation after paging would fail to mark it no-map because no-map flag works when doing direct mapping. This seems to be a circular dependency. Thank You, Calvin
On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote: > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote: > > The count of reserved regions in /reserved-memory was limited because > > the struct reserved_mem array was defined statically. This series sorts > > out reserved memory code and allocates that array from early allocator. > > > > Note: reserved region with fixed location must be reserved before any > > memory allocation. While struct reserved_mem array should be allocated > > after allocator is activated. We make early_init_fdt_scan_reserved_mem() > > do reservation only and add another call to initialize reserved memory. > > So arch code have to change for it. > > I think much simpler would be to use the same constant for sizing > memblock.reserved and reserved_mem arrays. Do those arrays get shrunk? Or do we waste the memory forever? Maybe we can copy and shrink the initial array? Though I suspect struct reserved_mem pointers have already been given out. > > If there is too much reserved regions in the device tree, reserving them in > memblock will fail anyway because memblock also starts with static array > for memblock.reserved, so doing one pass with memblock_reserve() and > another to set up reserved_mem wouldn't help anyway. > > > I'm only familiar with arm and arm64 architectures. Approvals from arch > > maintainers are required. Thank you all. > > > > Calvin Zhang (2): > > of: Sort reserved_mem related code > > of: reserved_mem: Remove reserved regions count restriction > > > > arch/arc/mm/init.c | 3 + > > arch/arm/kernel/setup.c | 2 + > > arch/arm64/kernel/setup.c | 3 + > > arch/csky/kernel/setup.c | 3 + > > arch/h8300/kernel/setup.c | 2 + > > arch/mips/kernel/setup.c | 3 + > > arch/nds32/kernel/setup.c | 3 + > > arch/nios2/kernel/setup.c | 2 + > > arch/openrisc/kernel/setup.c | 3 + > > arch/powerpc/kernel/setup-common.c | 3 + > > arch/riscv/kernel/setup.c | 2 + > > arch/sh/kernel/setup.c | 3 + > > arch/xtensa/kernel/setup.c | 2 + > > drivers/of/fdt.c | 107 +--------------- > > drivers/of/of_private.h | 12 +- > > drivers/of/of_reserved_mem.c | 189 ++++++++++++++++++++++++----- > > include/linux/of_reserved_mem.h | 4 + > > 17 files changed, 207 insertions(+), 139 deletions(-) > > > > -- > > 2.30.2 > > > > -- > Sincerely yours, > Mike. >
On Mon, Nov 29, 2021 at 06:08:10PM -0600, Rob Herring wrote: > On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote: > > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote: > > > The count of reserved regions in /reserved-memory was limited because > > > the struct reserved_mem array was defined statically. This series sorts > > > out reserved memory code and allocates that array from early allocator. > > > > > > Note: reserved region with fixed location must be reserved before any > > > memory allocation. While struct reserved_mem array should be allocated > > > after allocator is activated. We make early_init_fdt_scan_reserved_mem() > > > do reservation only and add another call to initialize reserved memory. > > > So arch code have to change for it. > > > > I think much simpler would be to use the same constant for sizing > > memblock.reserved and reserved_mem arrays. > > Do those arrays get shrunk? Or do we waste the memory forever? Memblock arrays don't get shrunk, but they are __init unless an architecture chose to keep them after boot, but most architectures that use device tree actually keep memblock structures. > Maybe we can copy and shrink the initial array? Though I suspect struct > reserved_mem pointers have already been given out. I'm not sure. It seems that reserved_mem pointers are given out at initcall time and AFAIU the reserved_mem array is created somewhere around setup_arch(). So maybe it's possible to copy and shrink the initial array. > > > > If there is too much reserved regions in the device tree, reserving them in > > memblock will fail anyway because memblock also starts with static array > > for memblock.reserved, so doing one pass with memblock_reserve() and > > another to set up reserved_mem wouldn't help anyway. > > > > > I'm only familiar with arm and arm64 architectures. Approvals from arch > > > maintainers are required. Thank you all.