Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On Wed, May 12, 2021 at 09:59:33AM +0200, Ard Biesheuvel wrote: > On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote: > > > > On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > > > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > > > > > From: Mike Rapoport > > > > > > > > Hi, > > > > > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially > > > > hardwire > > > > pfn_valid_within() to 1. > > > > > > > > The idea is to mark NOMAP pages as reserved in the memory map and > > > > restore > > > > the intended semantics of pfn_valid() to designate availability of > > > > struct > > > > page for a pfn. > > > > > > > > With this the core mm will be able to cope with the fact that it cannot > > > > use > > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER > > > > blocks > > > > will be treated correctly even without the need for pfn_valid_within. > > > > > > > > The patches are boot tested on qemu-system-aarch64. > > > > > > > > > > Did you use EFI boot when testing this? The memory map is much more > > > fragmented in that case, so this would be a good data point. > > > > Right, something like this: > > > > Yes, although it is not always that bad. > > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x4000-0xbfff] > > [0.00] node 0: [mem 0xc000-0x] > > This is allocated below 4 GB by the firmware, for reasons that are > only valid on x86 (where some of the early boot chain is IA32 only) > > > [0.00] node 0: [mem 0x0001-0x0004386f] > > [0.00] node 0: [mem 0x00043870-0x00043899] > > [0.00] node 0: [mem 0x0004389a-0x0004389b] > > [0.00] node 0: [mem 0x0004389c-0x000438b5] > > [0.00] node 0: [mem 0x000438b6-0x00043be3] > > [0.00] node 0: [mem 0x00043be4-0x00043bec] > > [0.00] node 0: [mem 0x00043bed-0x00043bed] > > [0.00] node 0: [mem 0x00043bee-0x00043bff] > > [0.00] node 0: [mem 0x00043c00-0x00043fff] > > > > This is a pity really, because I don't see a fundamental reason for those > > tiny holes all over the place. > > > > There is a config option in the firmware build that allows these > regions to be preallocated using larger windows, which greatly reduces > the fragmentation. > > I know that EFI/ACPI mandates "IO style" memory access for those regions, > > but I fail to get why... > > > > Not sure what you mean by 'IO style memory access'. Well, my understanding is that the memory reserved by the firmware cannot be mapped in the linear map because it might require different caching modes (e.g like IO) and arm64 cannot tolerate aliased mappings with different caching. But what evades me is *why* these areas cannot be accessed as normal RAM. > > > > I beleive it would be best to route these via mmotm tree. > > > > > > > > v4: > > > > * rebase on v5.13-rc1 > > > > > > > > v3: Link: > > > > https://lore.kernel.org/lkml/20210422061902.21614-1-r...@kernel.org > > > > * Fix minor issues found by Anshuman > > > > * Freshen up the declaration of pfn_valid() to make it consistent with > > > > pfn_is_map_memory() > > > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > > > > > v2: Link: > > > > https://lore.kernel.org/lkml/20210421065108.1987-1-r...@kernel.org > > > > * Add check for PFN overflow in pfn_is_map_memory() > > > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > > > > > v1: Link: > > > > https://lore.kernel.org/lkml/20210420090925.7457-1-r...@kernel.org > > > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > > > * Use pfn_is_map_memory() name for the exported wrapper for > > > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > > > because of header dependency issues. > > > > > > > > rfc: Link: > > > > https://lore.kernel.org/lkml/20210407172607.8812-1-r...@kernel.org > > > > > > > > Mike Rapoport (4): > > > > include/linux/mmzone.h: add documentation for pfn_valid() > > > > memblock: update initialization of reserved pages > > > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > > > > > arch/arm64/Kconfig | 3 --- > > > > arch/arm64/include/asm/memory.h | 2 +- > > > > arch/arm64/include/asm/page.h | 3 ++- > > > > arch/arm64/kvm/mmu.c| 2 +- > > > > arch/arm64/mm/init.c| 14 +- > > > > arch/arm64/mm/ioremap.c | 4 ++-- > > > > arch/arm64/mm/mmu.c | 2 +- > > > > include/linux/memblock.h| 4 +++- > > > > include/linux/mmzone.h | 11
Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote: > > On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > > > From: Mike Rapoport > > > > > > Hi, > > > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > > > pfn_valid_within() to 1. > > > > > > The idea is to mark NOMAP pages as reserved in the memory map and restore > > > the intended semantics of pfn_valid() to designate availability of struct > > > page for a pfn. > > > > > > With this the core mm will be able to cope with the fact that it cannot > > > use > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > > > will be treated correctly even without the need for pfn_valid_within. > > > > > > The patches are boot tested on qemu-system-aarch64. > > > > > > > Did you use EFI boot when testing this? The memory map is much more > > fragmented in that case, so this would be a good data point. > > Right, something like this: > Yes, although it is not always that bad. > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x4000-0xbfff] > [0.00] node 0: [mem 0xc000-0x] This is allocated below 4 GB by the firmware, for reasons that are only valid on x86 (where some of the early boot chain is IA32 only) > [0.00] node 0: [mem 0x0001-0x0004386f] > [0.00] node 0: [mem 0x00043870-0x00043899] > [0.00] node 0: [mem 0x0004389a-0x0004389b] > [0.00] node 0: [mem 0x0004389c-0x000438b5] > [0.00] node 0: [mem 0x000438b6-0x00043be3] > [0.00] node 0: [mem 0x00043be4-0x00043bec] > [0.00] node 0: [mem 0x00043bed-0x00043bed] > [0.00] node 0: [mem 0x00043bee-0x00043bff] > [0.00] node 0: [mem 0x00043c00-0x00043fff] > > This is a pity really, because I don't see a fundamental reason for those > tiny holes all over the place. > There is a config option in the firmware build that allows these regions to be preallocated using larger windows, which greatly reduces the fragmentation. > I know that EFI/ACPI mandates "IO style" memory access for those regions, > but I fail to get why... > Not sure what you mean by 'IO style memory access'. > > > I beleive it would be best to route these via mmotm tree. > > > > > > v4: > > > * rebase on v5.13-rc1 > > > > > > v3: Link: > > > https://lore.kernel.org/lkml/20210422061902.21614-1-r...@kernel.org > > > * Fix minor issues found by Anshuman > > > * Freshen up the declaration of pfn_valid() to make it consistent with > > > pfn_is_map_memory() > > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > > > v2: Link: > > > https://lore.kernel.org/lkml/20210421065108.1987-1-r...@kernel.org > > > * Add check for PFN overflow in pfn_is_map_memory() > > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > > > v1: Link: > > > https://lore.kernel.org/lkml/20210420090925.7457-1-r...@kernel.org > > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > > * Use pfn_is_map_memory() name for the exported wrapper for > > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > > because of header dependency issues. > > > > > > rfc: Link: > > > https://lore.kernel.org/lkml/20210407172607.8812-1-r...@kernel.org > > > > > > Mike Rapoport (4): > > > include/linux/mmzone.h: add documentation for pfn_valid() > > > memblock: update initialization of reserved pages > > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > > > arch/arm64/Kconfig | 3 --- > > > arch/arm64/include/asm/memory.h | 2 +- > > > arch/arm64/include/asm/page.h | 3 ++- > > > arch/arm64/kvm/mmu.c| 2 +- > > > arch/arm64/mm/init.c| 14 +- > > > arch/arm64/mm/ioremap.c | 4 ++-- > > > arch/arm64/mm/mmu.c | 2 +- > > > include/linux/memblock.h| 4 +++- > > > include/linux/mmzone.h | 11 +++ > > > mm/memblock.c | 28 ++-- > > > 10 files changed, 60 insertions(+), 13 deletions(-) > > > > > > > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > > > -- > > > 2.28.0 > > > > > -- > Sincerely yours, > Mike. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote: > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Hi, > > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > > pfn_valid_within() to 1. > > > > The idea is to mark NOMAP pages as reserved in the memory map and restore > > the intended semantics of pfn_valid() to designate availability of struct > > page for a pfn. > > > > With this the core mm will be able to cope with the fact that it cannot use > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > > will be treated correctly even without the need for pfn_valid_within. > > > > The patches are boot tested on qemu-system-aarch64. > > > > Did you use EFI boot when testing this? The memory map is much more > fragmented in that case, so this would be a good data point. Right, something like this: [0.00] Early memory node ranges [0.00] node 0: [mem 0x4000-0xbfff] [0.00] node 0: [mem 0xc000-0x] [0.00] node 0: [mem 0x0001-0x0004386f] [0.00] node 0: [mem 0x00043870-0x00043899] [0.00] node 0: [mem 0x0004389a-0x0004389b] [0.00] node 0: [mem 0x0004389c-0x000438b5] [0.00] node 0: [mem 0x000438b6-0x00043be3] [0.00] node 0: [mem 0x00043be4-0x00043bec] [0.00] node 0: [mem 0x00043bed-0x00043bed] [0.00] node 0: [mem 0x00043bee-0x00043bff] [0.00] node 0: [mem 0x00043c00-0x00043fff] This is a pity really, because I don't see a fundamental reason for those tiny holes all over the place. I know that EFI/ACPI mandates "IO style" memory access for those regions, but I fail to get why... > > I beleive it would be best to route these via mmotm tree. > > > > v4: > > * rebase on v5.13-rc1 > > > > v3: Link: > > https://lore.kernel.org/lkml/20210422061902.21614-1-r...@kernel.org > > * Fix minor issues found by Anshuman > > * Freshen up the declaration of pfn_valid() to make it consistent with > > pfn_is_map_memory() > > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > > > v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-r...@kernel.org > > * Add check for PFN overflow in pfn_is_map_memory() > > * Add Acked-by and Reviewed-by tags, thanks David. > > > > v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-r...@kernel.org > > * Add comment about the semantics of pfn_valid() as Anshuman suggested > > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > > * Use pfn_is_map_memory() name for the exported wrapper for > > memblock_is_map_memory(). It is still local to arch/arm64 in the end > > because of header dependency issues. > > > > rfc: Link: > > https://lore.kernel.org/lkml/20210407172607.8812-1-r...@kernel.org > > > > Mike Rapoport (4): > > include/linux/mmzone.h: add documentation for pfn_valid() > > memblock: update initialization of reserved pages > > arm64: decouple check whether pfn is in linear map from pfn_valid() > > arm64: drop pfn_valid_within() and simplify pfn_valid() > > > > arch/arm64/Kconfig | 3 --- > > arch/arm64/include/asm/memory.h | 2 +- > > arch/arm64/include/asm/page.h | 3 ++- > > arch/arm64/kvm/mmu.c| 2 +- > > arch/arm64/mm/init.c| 14 +- > > arch/arm64/mm/ioremap.c | 4 ++-- > > arch/arm64/mm/mmu.c | 2 +- > > include/linux/memblock.h| 4 +++- > > include/linux/mmzone.h | 11 +++ > > mm/memblock.c | 28 ++-- > > 10 files changed, 60 insertions(+), 13 deletions(-) > > > > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > > -- > > 2.28.0 > > -- Sincerely yours, Mike. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On 2021/5/11 18:05, Mike Rapoport wrote: From: Mike Rapoport Hi, These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire pfn_valid_within() to 1. The idea is to mark NOMAP pages as reserved in the memory map and restore the intended semantics of pfn_valid() to designate availability of struct page for a pfn. With this the core mm will be able to cope with the fact that it cannot use NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks will be treated correctly even without the need for pfn_valid_within. The patches are boot tested on qemu-system-aarch64. I beleive it would be best to route these via mmotm tree. Reviewed-by: Kefeng Wang ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote: > > From: Mike Rapoport > > Hi, > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire > pfn_valid_within() to 1. > > The idea is to mark NOMAP pages as reserved in the memory map and restore > the intended semantics of pfn_valid() to designate availability of struct > page for a pfn. > > With this the core mm will be able to cope with the fact that it cannot use > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks > will be treated correctly even without the need for pfn_valid_within. > > The patches are boot tested on qemu-system-aarch64. > Did you use EFI boot when testing this? The memory map is much more fragmented in that case, so this would be a good data point. > I beleive it would be best to route these via mmotm tree. > > v4: > * rebase on v5.13-rc1 > > v3: Link: https://lore.kernel.org/lkml/20210422061902.21614-1-r...@kernel.org > * Fix minor issues found by Anshuman > * Freshen up the declaration of pfn_valid() to make it consistent with > pfn_is_map_memory() > * Add more Acked-by and Reviewed-by tags, thanks Anshuman and David > > v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-r...@kernel.org > * Add check for PFN overflow in pfn_is_map_memory() > * Add Acked-by and Reviewed-by tags, thanks David. > > v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-r...@kernel.org > * Add comment about the semantics of pfn_valid() as Anshuman suggested > * Extend comments about MEMBLOCK_NOMAP, per Anshuman > * Use pfn_is_map_memory() name for the exported wrapper for > memblock_is_map_memory(). It is still local to arch/arm64 in the end > because of header dependency issues. > > rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-r...@kernel.org > > Mike Rapoport (4): > include/linux/mmzone.h: add documentation for pfn_valid() > memblock: update initialization of reserved pages > arm64: decouple check whether pfn is in linear map from pfn_valid() > arm64: drop pfn_valid_within() and simplify pfn_valid() > > arch/arm64/Kconfig | 3 --- > arch/arm64/include/asm/memory.h | 2 +- > arch/arm64/include/asm/page.h | 3 ++- > arch/arm64/kvm/mmu.c| 2 +- > arch/arm64/mm/init.c| 14 +- > arch/arm64/mm/ioremap.c | 4 ++-- > arch/arm64/mm/mmu.c | 2 +- > include/linux/memblock.h| 4 +++- > include/linux/mmzone.h | 11 +++ > mm/memblock.c | 28 ++-- > 10 files changed, 60 insertions(+), 13 deletions(-) > > > base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 > -- > 2.28.0 > ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
