Re: [PATCH v2 0/8] Introduce sv48 support

[Alex Ghiti]

Hi Palmer,

Le 7/1/20 Ã 2:27 PM, Palmer Dabbelt a ÃcritÂ:
> On Wed, 03 Jun 2020 01:10:56 PDT (-0700), alex@xxxxxxxx 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(-)