Messages in this thread | | | From | Alex Ghiti <> | Subject | Re: [PATCH v2 0/8] Introduce sv48 support | Date | Fri, 3 Jul 2020 01:22:33 -0400 |
| |
Hi Palmer,
Le 7/1/20 à 2:27 PM, Palmer Dabbelt a écrit : > On Wed, 03 Jun 2020 01:10:56 PDT (-0700), alex@ghiti.fr wrote: >> This patchset implements sv48 support at runtime. The kernel will try to >> boot with 4-level page table and will fallback to 3-level if the HW >> does not >> support it. >> >> The biggest advantage is that we only have one kernel for 64bit, which >> is way easier to maintain. >> >> Folding the 4th level into a 3-level page table has almost no cost at >> runtime. But as mentioned Palmer, the relocatable code generated is less >> performant. >> >> At the moment, there is no way to build a 3-level page table >> non-relocatable >> 64bit kernel. We agreed that distributions will use this runtime >> configuration >> anyway, but Palmer proposed to introduce a new Kconfig, which I will >> do later >> as sv48 support was asked for 5.8. > > Sorry I wasn't clear last time, but this still has the same fundamental > issue: > it forces 64-bit kernels to be relocatable, which imposes a performance > penalty. We don't have any hardware that can actually take advantage of > sv48, > so I don't want to take anything that penalizes what people are actually > using > in order to add a feature people can't use. > > I'd be OK taking this if sv48 support simply depended on a relocatable > kernel, > as then users who want the faster kernel could still build one. I don't > want > to take something that forces all 64-bit kernels to be relocatable.
Indeed, I had not understood that this was a requirement. I will add a patch on top of this one introducing a new config, I have to think about it.
But even if I understand that the new level of indirection coming with PIE will be slower, is this new config worth it ? Can we benchmark somehow the performance loss ? IMHO I think that this config will get broken over time by lack of testing because I believe distributions will go for KASLR kernel which requires the relocatability property anyway.
Alex
> >> Finally, the user can now ask for sv39 explicitly by using the >> device-tree >> which will reduce memory footprint and reduce the number of memory >> accesses >> in case of TLB miss. >> >> Changes in v2: >> * Move variable declarations to pgtable.h in patch 5/7 as suggested >> by Anup >> * Restore mmu-type properties in patch 6 as suggested by Anup >> * Fix unused variable in patch 5 that was used in patch 6 >> * Fix SPARSEMEM build (patch 2 was modified so I dropped the >> Reviewed-by) >> * Applied various Reviewed-by >> >> Alexandre Ghiti (8): >> riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE >> riscv: Allow to dynamically define VA_BITS >> riscv: Simplify MAXPHYSMEM config >> riscv: Prepare ptdump for vm layout dynamic addresses >> riscv: Implement sv48 support >> riscv: Allow user to downgrade to sv39 when hw supports sv48 >> riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo >> riscv: Explicit comment about user virtual address space size >> >> arch/riscv/Kconfig | 34 ++--- >> arch/riscv/include/asm/csr.h | 3 +- >> arch/riscv/include/asm/fixmap.h | 1 + >> arch/riscv/include/asm/page.h | 15 +++ >> arch/riscv/include/asm/pgalloc.h | 36 ++++++ >> arch/riscv/include/asm/pgtable-64.h | 97 +++++++++++++- >> arch/riscv/include/asm/pgtable.h | 31 ++++- >> arch/riscv/include/asm/sparsemem.h | 6 +- >> arch/riscv/kernel/cpu.c | 23 ++-- >> arch/riscv/kernel/head.S | 3 +- >> arch/riscv/mm/context.c | 2 +- >> arch/riscv/mm/init.c | 194 ++++++++++++++++++++++++---- >> arch/riscv/mm/ptdump.c | 49 +++++-- >> 13 files changed, 412 insertions(+), 82 deletions(-)
| |