| Message ID | 20221018222503.90118-2-giulio.benetti@benettiengineering.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/2] ARM: mm: fix no-MMU ZERO_PAGE() implementation | expand |
On Wed, Oct 19, 2022 at 12:25:03AM +0200, Giulio Benetti wrote: > ARM architecture is the only one to have empty_zero_page to be a > struct page pointer, while in all other implementations empty_zero_page is > a data pointer or directly an array(the zero page itself). So let's convert > empty_zero_page to an array for consistency and to avoid an early > allocation+dcache flush. Being the array in .bss it will be cleared earlier > in a more linear way(and a bit faster) way. > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> I'm completely against this approach. It introduces inefficiencies in paths we don't need, and also means that the zero page is at a fixed location relative to the kernel, neither of which I like in the slightest. Thanks.
Hello Russell, On 19/10/22 16:44, Russell King (Oracle) wrote: > On Wed, Oct 19, 2022 at 12:25:03AM +0200, Giulio Benetti wrote: >> ARM architecture is the only one to have empty_zero_page to be a >> struct page pointer, while in all other implementations empty_zero_page is >> a data pointer or directly an array(the zero page itself). So let's convert >> empty_zero_page to an array for consistency and to avoid an early >> allocation+dcache flush. Being the array in .bss it will be cleared earlier >> in a more linear way(and a bit faster) way. >> >> Suggested-by: Arnd Bergmann <arnd@arndb.de> >> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> > > I'm completely against this approach. It introduces inefficiencies in > paths we don't need, and also means that the zero page is at a fixed > location relative to the kernel, neither of which I like in the > slightest. I haven't considered those details, I'm pretty new in this topic. I was thinking with a no-mmu approach in my mind, that's why the .bss approach. And also the exposure of the entire array to the other subsystem is not a good idea. Thank you for pointing me Best regads
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h index ef48a55e9af8..de402b345f55 100644 --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -15,8 +15,8 @@ * ZERO_PAGE is a global shared page that is always zero: used * for zero-mapped memory areas etc.. */ -extern struct page *empty_zero_page; -#define ZERO_PAGE(vaddr) (empty_zero_page) +extern unsigned long empty_zero_page[]; +#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page)) #endif #ifndef CONFIG_MMU diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 463fc2a8448f..f05a5471a45a 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -45,7 +45,7 @@ extern unsigned long __atags_pointer; * empty_zero_page is a special page that is used for * zero-initialized data and COW. */ -struct page *empty_zero_page; +unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss; EXPORT_SYMBOL(empty_zero_page); /* @@ -1760,8 +1760,6 @@ static void __init early_fixmap_shutdown(void) */ void __init paging_init(const struct machine_desc *mdesc) { - void *zero_page; - pr_debug("physical kernel sections: 0x%08llx-0x%08llx\n", kernel_sec_start, kernel_sec_end); @@ -1782,13 +1780,7 @@ void __init paging_init(const struct machine_desc *mdesc) top_pmd = pmd_off_k(0xffff0000); - /* allocate the zero page. */ - zero_page = early_alloc(PAGE_SIZE); - bootmem_init(); - - empty_zero_page = virt_to_page(zero_page); - __flush_dcache_page(NULL, empty_zero_page); } void __init early_mm_init(const struct machine_desc *mdesc) diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c index c1494a4dee25..e0c3f59d1c5a 100644 --- a/arch/arm/mm/nommu.c +++ b/arch/arm/mm/nommu.c @@ -30,7 +30,7 @@ unsigned long vectors_base; * empty_zero_page is a special page that is used for * zero-initialized data and COW. */ -struct page *empty_zero_page; +unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss; EXPORT_SYMBOL(empty_zero_page); #ifdef CONFIG_ARM_MPU @@ -155,21 +155,9 @@ void __init adjust_lowmem_bounds(void) */ void __init paging_init(const struct machine_desc *mdesc) { - void *zero_page; - early_trap_init((void *)vectors_base); mpu_setup(); - - /* allocate the zero page. */ - zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE); - if (!zero_page) - panic("%s: Failed to allocate %lu bytes align=0x%lx\n", - __func__, PAGE_SIZE, PAGE_SIZE); - bootmem_init(); - - empty_zero_page = virt_to_page(zero_page); - flush_dcache_page(empty_zero_page); } /*
ARM architecture is the only one to have empty_zero_page to be a struct page pointer, while in all other implementations empty_zero_page is a data pointer or directly an array(the zero page itself). So let's convert empty_zero_page to an array for consistency and to avoid an early allocation+dcache flush. Being the array in .bss it will be cleared earlier in a more linear way(and a bit faster) way. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> --- V1->V2: * create patch suggested by Arnd Bergmann --- arch/arm/include/asm/pgtable.h | 4 ++-- arch/arm/mm/mmu.c | 10 +--------- arch/arm/mm/nommu.c | 14 +------------- 3 files changed, 4 insertions(+), 24 deletions(-)