Subject: [RFC] ARM64: 4 level page table translation for 4KB pages

From: [email-masked] (Catalin Marinas)
Date: Tue, 1 Apr 2014 12:22:34 +0100

On Tue, Apr 01, 2014 at 11:13:27AM +0100, ??? wrote:
> On Tuesday, April 01, 2014 6:47 PM, Catalin Marinas wrote:
> > On Tue, Apr 01, 2014 at 01:44:36AM +0100, ??? wrote:
> > > On Tuesday, April 01, 2014 12:27 AM Catalin Marinas wrote:
> > > > I don't mind 4-level tables by default but I would still keep a
> > > > configuration option (or at least doing some benchmarks to assess the
> > > > impact before switching permanently to 4-levels). There are mobile
> > > > platforms that don't really need as much VA space (and people are even
> > > > talking about ILP32).
> > >
> > > How about keep 3-level table by default and enable 4-level table with
> > > config option?
> > 
> > We want single image, so the default should cover all platforms. If
> > someone wants to deploy a more specific kernel (e.g. for a mobile
> > platform), they could change the configuration to more suitable ones.
> Single image would have merit but I think one way should be default 
> Configuration and another should be specific kernel for smaller or lager 
> memory platform.
> Which one do you want as default configuration among 3 level and 4 level?

The default should be 4 levels to cover all cases. You can tweak the
config for your platform if you want to deploy a specific kernel image.

> > > Asymmetry level for kernel and user land would make code complicated.
> > > And usually more memory means that user application tends to use more memory.
> > > So I suggest same virtual space for both.
> > 
> > I don't really get the "more memory means ..." above ;). It's more
> > virtual space, the user application would not extend to use all of it
> > (most likely won't even notice).
> The reason why we need 4 level page table is originally is that we need
> bigger physical memory and kernel does not have enough virtual space.

So, you need more virtual space in the kernel to be able to linearly map
the physical address space. That's fine.

> Please consider this is not only for making virtual bigger.
> It's to make system use large physical memory for user application.

Do you want to use more than 512GB of physical memory for a user
application?

-- 
Catalin