From: Arnd Bergmann <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions
Date: Mon, 25 Oct 2010 13:15:53 +0200 [thread overview]
Message-ID: <201010251315.53304.arnd@arndb.de> (raw)
In-Reply-To: <20101025090007.25275.99918.stgit@e102109-lin.cambridge.arm.com>
On Monday 25 October 2010, Catalin Marinas wrote:
> +/*
> + * With LPAE, there are 3 levels of page tables. Each level has 512 entries of
> + * 8 bytes each, occupying a 4K page. The first level table covers a range of
> + * 512GB, each entry representing 1GB. Since we are limited to 4GB input
> + * address range, only 4 entries in the PGD are used.
> + *
> + * There are enough spare bits in a page table entry for the kernel specific
> + * state.
> + */
> +#define PTRS_PER_PTE 512
> +#define PTRS_PER_PMD 512
> +#define PTRS_PER_PGD 4
Since the PGD is so extremely small, would it be possible to fold it
into the mm_context_t in order to save an allocation?
Or does the PGD still require page alignment?
Do you also have patches to allow 40-bit virtual space? I suppose we
will need that for KVM support in the future.
Arnd
next prev parent reply other threads:[~2010-10-25 11:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-25 8:59 [RFC PATCH 00/18] ARM: Add support for the Large Physical Address Extensions Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 01/18] ARM: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_* Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 02/18] ARM: LPAE: Factor out 2-level page table definitions into separate files Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 03/18] ARM: LPAE: use u32 instead of unsigned long for 32-bit ptes Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 04/18] ARM: LPAE: Do not assume Linux PTEs are always at PTRS_PER_PTE offset Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 05/18] ARM: LPAE: Introduce L_PTE_NOEXEC and L_PTE_NOWRITE Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions Catalin Marinas
2010-10-25 11:15 ` Arnd Bergmann [this message]
2010-10-25 11:59 ` Catalin Marinas
2010-10-25 13:25 ` Arnd Bergmann
2010-10-25 16:18 ` Catalin Marinas
2010-10-25 18:25 ` Arnd Bergmann
2010-12-06 9:27 ` Christoffer Dall
2010-12-06 14:21 ` Arnd Bergmann
2010-10-25 9:00 ` [RFC PATCH 07/18] ARM: LPAE: Page table maintenance for the 3-level format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 08/18] ARM: LPAE: MMU setup for the 3-level page table format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 09/18] ARM: LPAE: Add fault handling support Catalin Marinas
2010-10-25 10:17 ` Kirill A. Shutemov
2010-10-25 10:35 ` Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 10/18] ARM: LPAE: Add context switching support Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 11/18] ARM: LPAE: Add SMP support for the 3-level page table format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 12/18] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 13/18] ARM: LPAE: ensure dma_addr_t is the same size as phys_addr_t Catalin Marinas
2010-10-25 11:08 ` Arnd Bergmann
2010-10-25 11:32 ` Catalin Marinas
2010-10-25 12:01 ` FUJITA Tomonori
2010-10-25 12:31 ` Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 14/18] ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 15/18] ARM: LPAE: use phys_addr_t for physical start address in early_mem Catalin Marinas
2010-10-25 9:01 ` [RFC PATCH 16/18] ARM: LPAE: add support for ATAG_MEM64 Catalin Marinas
2010-10-25 9:01 ` [RFC PATCH 17/18] ARM: LPAE: define printk format for physical addresses and page table entries Catalin Marinas
2010-10-25 12:01 ` Kirill A. Shutemov
2010-10-25 9:01 ` [RFC PATCH 18/18] ARM: LPAE: Add the Kconfig entries Catalin Marinas
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=201010251315.53304.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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