All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jungseok Lee <jays.lee@samsung.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"steve.capper@linaro.org" <steve.capper@linaro.org>,
	"sungjinn.chung@samsung.com" <sungjinn.chung@samsung.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
	"ilho215.lee@samsung.com" <ilho215.lee@samsung.com>
Subject: Re: [PATCH v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages
Date: Tue, 29 Apr 2014 15:47:59 +0100	[thread overview]
Message-ID: <20140429144759.GL17007@arm.com> (raw)
In-Reply-To: <000401cf6367$cc461500$64d23f00$@samsung.com>

On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote:
> --- a/Documentation/arm64/memory.txt
> +++ b/Documentation/arm64/memory.txt
> @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64
>  Linux kernel. The architecture allows up to 4 levels of translation
>  tables with a 4KB page size and up to 3 levels with a 64KB page size.
>  
> -AArch64 Linux uses 3 levels of translation tables with the 4KB page
> -configuration, allowing 39-bit (512GB) virtual addresses for both user
> -and kernel. With 64KB pages, only 2 levels of translation tables are
> -used but the memory layout is the same.
> +AArch64 Linux uses 3 levels and 4 levels of translation tables with
> +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB)
> +virtual addresses, respectively, for both user and kernel. With 64KB
> +pages, only 2 levels of translation tables are used but the memory layout
> +is the same.

Any reason why we couldn't use 48-bit address space with 64K pages
(implying 3 levels)?

> -AArch64 Linux memory layout with 64KB pages:
> +AArch64 Linux memory layout with 4KB pages + 4 levels:
> +
> +Start			End			Size		Use
> +-----------------------------------------------------------------------
> +0000000000000000	0000ffffffffffff	 256TB		user
> +
> +ffff000000000000	ffff7bfffffeffff	~124TB		vmalloc

BTW, maybe as a separate patch we should change the "end" to be
exclusive. It becomes harder to modify (I've been through this a few
times already ;)) and even follow the changes.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages
Date: Tue, 29 Apr 2014 15:47:59 +0100	[thread overview]
Message-ID: <20140429144759.GL17007@arm.com> (raw)
In-Reply-To: <000401cf6367$cc461500$64d23f00$@samsung.com>

On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote:
> --- a/Documentation/arm64/memory.txt
> +++ b/Documentation/arm64/memory.txt
> @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64
>  Linux kernel. The architecture allows up to 4 levels of translation
>  tables with a 4KB page size and up to 3 levels with a 64KB page size.
>  
> -AArch64 Linux uses 3 levels of translation tables with the 4KB page
> -configuration, allowing 39-bit (512GB) virtual addresses for both user
> -and kernel. With 64KB pages, only 2 levels of translation tables are
> -used but the memory layout is the same.
> +AArch64 Linux uses 3 levels and 4 levels of translation tables with
> +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB)
> +virtual addresses, respectively, for both user and kernel. With 64KB
> +pages, only 2 levels of translation tables are used but the memory layout
> +is the same.

Any reason why we couldn't use 48-bit address space with 64K pages
(implying 3 levels)?

> -AArch64 Linux memory layout with 64KB pages:
> +AArch64 Linux memory layout with 4KB pages + 4 levels:
> +
> +Start			End			Size		Use
> +-----------------------------------------------------------------------
> +0000000000000000	0000ffffffffffff	 256TB		user
> +
> +ffff000000000000	ffff7bfffffeffff	~124TB		vmalloc

BTW, maybe as a separate patch we should change the "end" to be
exclusive. It becomes harder to modify (I've been through this a few
times already ;)) and even follow the changes.

-- 
Catalin

  reply	other threads:[~2014-04-29 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  4:59 [PATCH v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages Jungseok Lee
2014-04-29  4:59 ` Jungseok Lee
2014-04-29 14:47 ` Catalin Marinas [this message]
2014-04-29 14:47   ` Catalin Marinas
2014-04-30  6:41   ` Jungseok Lee
2014-04-30  6:41     ` Jungseok Lee
2014-04-30 13:12     ` Catalin Marinas
2014-04-30 13:12       ` Catalin Marinas
2014-05-01  0:53       ` Jungseok Lee
2014-05-01  0:53         ` 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=20140429144759.GL17007@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=arnd@arndb.de \
    --cc=christoffer.dall@linaro.org \
    --cc=ilho215.lee@samsung.com \
    --cc=jays.lee@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=steve.capper@linaro.org \
    --cc=sungjinn.chung@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.