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 10:46:48 +0100 [thread overview]
Message-ID: <20140401094648.GB20061@arm.com> (raw)
In-Reply-To: <000501cf4d43$90e618a0$b2b249e0$%chung@samsung.com>
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.
> 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).
Asymmetry wouldn't make things much more complicated. You can even
pretend you have 4 levels configured but used pgd_offset tricks to
effectively use 3 hardware levels.
--
Catalin
next prev parent reply other threads:[~2014-04-01 9:46 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 [this message]
2014-04-01 10:13 ` 정성진
2014-04-01 11:22 ` Catalin Marinas
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=20140401094648.GB20061@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).