linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] ARM64: 4 level page table translation for 4KB pages
Date: Tue, 1 Apr 2014 12:22:34 +0100	[thread overview]
Message-ID: <20140401112234.GC20061@arm.com> (raw)
In-Reply-To: <000c01cf4d93$0863e750$192bb5f0$%chung@samsung.com>

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

  reply	other threads:[~2014-04-01 11:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31  3:51 [RFC] ARM64: 4 level page table translation for 4KB pages Jungseok Lee
2014-03-31  6:56 ` Arnd Bergmann
2014-03-31 11:31   ` Catalin Marinas
2014-03-31 12:45     ` Catalin Marinas
2014-03-31 12:58       ` Arnd Bergmann
2014-03-31 15:00         ` Catalin Marinas
2014-03-31 12:53     ` Arnd Bergmann
2014-03-31 15:27       ` Catalin Marinas
2014-03-31 23:11         ` Arnd Bergmann
2014-04-01 13:23           ` Catalin Marinas
2014-04-02  3:58             ` Jungseok Lee
2014-04-02  9:01               ` Catalin Marinas
2014-04-02 15:24                 ` Catalin Marinas
2014-04-02 22:41                   ` Jungseok Lee
2014-04-03  2:15                   ` Sungjinn Chung
2014-04-03  8:38                     ` Catalin Marinas
2014-04-03  9:14                       ` Sungjinn Chung
2014-04-03  9:17                         ` Catalin Marinas
2014-04-01  0:44         ` 정성진
2014-04-01  9:46           ` Catalin Marinas
2014-04-01 10:13             ` 정성진
2014-04-01 11:22               ` Catalin Marinas [this message]
2014-04-01 23:35                 ` Sungjinn Chung
2014-04-01  0:42     ` Jungseok Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140401112234.GC20061@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).