Skip to contentSkip to conversation

ARM hugetlb support

RFC New bill4carson at gmail.com 3 participants 36 messages Jan 30, 2012 – Feb 7, 2012

Subsystems (2)
Arm (32-bit) MM core
lore
Share & tools
lore

bill4carson at gmail.com

author
#0 lore raw

Hi All

This patch aims to support huge page for ARM. For now, 2MB(two 1MB page)/16MB huge page are supported, Versatile Express Cortex-A9x4 tile is used as test board. Verifications are running with libhugetlbfs and ltp.

Any suggestions would be welcome.

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/Kconfig                      |   29 ++++
 arch/arm/include/asm/glue-proc.h      |    3 +
 arch/arm/include/asm/hugetlb.h        |  240 +++++++++++++++++++++++++++++++++
 arch/arm/include/asm/page.h           |   15 ++
 arch/arm/include/asm/pgtable-2level.h |    8 +
 arch/arm/include/asm/pgtable.h        |   28 ++++
 arch/arm/include/asm/proc-fns.h       |    3 +
 arch/arm/mm/Makefile                  |    1 +
 arch/arm/mm/dma-mapping.c             |    3 -
 arch/arm/mm/fault.c                   |   15 ++
 arch/arm/mm/hugetlb.c                 |  187 +++++++++++++++++++++++++
 arch/arm/mm/pgd.c                     |   28 ++++
 arch/arm/mm/proc-v7-2level.S          |   96 +++++++++++++
 include/linux/mm_types.h              |   11 ++
 14 files changed, 664 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/hugetlb.h
 create mode 100644 arch/arm/mm/hugetlb.c
author
#1 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

From: Bill Carson <[email protected]>

Why 2MB huge page is exported to user?

1M huge page only resides at pgd level, it does not need pte level stuff, Point is that huge page based VMA mingles with 4K page based VMA at pgd level no matter the page fault sequence of these two different VMA,
a pagefault at one VMA will contaminate the pgd entry of the other VMA.

example:

Create a 4K page based VMA and 1M page based VMA,

VMA_4K range is 0x40280000 ~ 0x40280400, pgd level index = 0x402 VMA_1M range is 0x40300000 ~ 0x40400000, pgd level index = 0x403

When page fault occurs at VMA_1M first, all we need to do is to allocate a 1M page, and setup one pgd entry at index 0x403;

then at the occurrence of page fault for VMA_4K, both pgd entries at index 0x402 and 0x403 are configured according to current ARM 4K page pagetable design, this will ruin the first VMA_1M page entry causing weird kernel oops; we cannot prejudge the sequence of page fault for VMA_4K and VMA_1M; Much of special cares need to to be taken to rule out such pagetable damages, this work involves heavy hacking of current 4K pagetale management, it is complex and prone to breakage.

The solution to this problem is to chose a page size that does not fall into the 4k page pgd entries pair, and the best one is using 2MB huge page.

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/include/asm/hugetlb.h |  240 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/page.h    |   15 +++
 arch/arm/mm/hugetlb.c          |  187 +++++++++++++++++++++++++++++++
 3 files changed, 442 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/hugetlb.h
 create mode 100644 arch/arm/mm/hugetlb.c
arch/arm/include/asm/hugetlb.h new file +240 -0
new file mode 100644
index 0000000..d7ad0fc
@@ -0,0 +1,240 @@
+/*
+ * hugetlb.h, ARM Huge Tlb Page support.
+ *
+ * Copyright (c) Bill Carson
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef __ASM_HUGETLB_H
+#define __ASM_HUGETLB_H
+
+#include <asm/page.h>
+#include <asm/pgtable-2level.h>
+#include <asm/tlb.h>
+
+
+/* 2M and 16M hugepage linux ptes are stored in an array
+ *
+ * 2M hugepage
+ * ===========
+ * one linux pte caters to two HW ptes,
+ * so the maximum huge linux pte needed is 4096M/2M = 2048 entry pointers.
+ * Two 4K page is used to store these entry pointers(2048 * 4 = 8192 bytes)
+ * in a two-dimension array, huge_2m_pte[2][1024].
+ *
+ * How to find the hugepage linux pte corresponding to a specific address ?
+ * VA[31] is used as row index;
+ * VA[30:21] is used as column  index;
+ *
+ * 16M hugepage
+ * ============
+ * one linux pte caters for one HW pte,
+ * so maxium huge linux pte needed is 4096M/16M = 256 entry pointers,
+ * 256 * 4 = 1024 bytes spaces is allocated to store these linux pte;
+ * this is a simple one-dimension array huge_16m_pte[256].
+ *
+ * VA[31:24] is used to index this array;
+ */
+
+/* 2M hugepage */
+#define HUGEPAGE_2M_PTE_ARRAY_ROW(addr)  ((addr & 0x80000000) >> 31)
+#define HUGEPAGE_2M_PTE_ARRAY_COL(addr)  ((addr & 0x7fe00000) >> 21)
+/* 16M hugepage */
+#define HUGEPAGE_16M_PTE_ARRAY_INDEX(addr)  ((addr & 0xff000000) >> 24)
+
+#define ALIGN_16M_PMD_ENTRY(pmd) ((unsigned long)pmd & (~0x3f))
+
+
+static inline int is_hugepage_only_range(struct mm_struct *mm,
+					 unsigned long addr,
+					 unsigned long len)
+{
+	return 0;
+}
+
+static inline int prepare_hugepage_range(struct file *file,
+					 unsigned long addr,
+					 unsigned long len)
+{
+	struct hstate *h = hstate_file(file);
+	/* addr/len should be aligned with huge page size */
+	if (len & ~huge_page_mask(h))
+		return -EINVAL;
+	if (addr & ~huge_page_mask(h))
+		return -EINVAL;
+
+	return 0;
+}
+
+static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
+{
+}
+
+static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
+			unsigned long addr, unsigned long end,
+			unsigned long floor, unsigned long ceiling)
+{
+}
+
+static inline void set_hugepte_section(struct mm_struct *mm, unsigned long addr,
+				   pte_t *ptep, pte_t pte)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+
+	int col, row;
+	pte_t **huge_linuxpte = &mm->huge_2m_pte[0];
+
+	row = HUGEPAGE_2M_PTE_ARRAY_ROW(addr);
+	col = HUGEPAGE_2M_PTE_ARRAY_COL(addr);
+
+	/* an valid pte pointer is expected */
+	BUG_ON(huge_linuxpte[row] == 0);
+	BUG_ON(ptep != &huge_linuxpte[row][col]);
+
+	/* set linux pte first */
+	huge_linuxpte[row][col] = pte;
+
+	/* set hardware pte */
+	pgd = pgd_offset(mm, addr);
+	pud = pud_offset(pgd, addr);
+	pmd = pmd_offset(pud, addr);
+
+	set_hugepte_at(mm, addr, pmd, pte);
+}
+
+static inline void set_hugepte_supersection(struct mm_struct *mm,
+			unsigned long addr, pte_t *ptep, pte_t pte)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+
+	int index;
+	pte_t *huge_linuxpte = mm->huge_16m_pte;
+
+	index = HUGEPAGE_16M_PTE_ARRAY_INDEX(addr);
+
+	BUG_ON(huge_linuxpte == 0);
+	BUG_ON(ptep != &huge_linuxpte[index]);
+
+	/* set linux pte first */
+	huge_linuxpte[index] = pte;
+
+	/* set hardware pte */
+	addr &= SUPERSECTION_MASK;
+	pgd = pgd_offset(mm, addr);
+	pud = pud_offset(pgd, addr);
+	pmd = pmd_offset(pud, addr);
+
+	set_hugepte_at(mm, addr, pmd, pte);
+}
+
+static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
+				   pte_t *ptep, pte_t pte)
+{
+	if (pte & L_PTE_HPAGE_2M)
+		set_hugepte_section(mm, addr, ptep, pte);
+	else
+		set_hugepte_supersection(mm, addr, ptep, pte);
+}
+
+static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
+					    unsigned long addr, pte_t *ptep)
+{
+	pte_t pte = *ptep;
+	pte_t fake = (L_PTE_HUGEPAGE | L_PTE_YOUNG);
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+
+	/* clear linux pte */
+	*ptep = 0;
+	pgd = pgd_offset(mm, addr);
+	pud = pud_offset(pgd, addr);
+	pmd = pmd_offset(pud, addr);
+
+	if (pte & L_PTE_HPAGE_16M) {
+		pmd = (pmd_t *)ALIGN_16M_PMD_ENTRY(pmd);
+		fake |= L_PTE_HPAGE_16M;
+
+	} else
+		fake |= L_PTE_HPAGE_2M;
+
+	/* let set_hugepte_at clear HW entry */
+	set_hugepte_at(mm, addr, pmd, fake);
+	return pte;
+}
+
+static inline void huge_ptep_clear_flush(struct vm_area_struct *vma,
+					 unsigned long addr, pte_t *ptep)
+{
+	if (*ptep & L_PTE_HPAGE_16M)
+		flush_tlb_page(vma, addr & SUPERSECTION_MASK);
+	else {
+		flush_tlb_page(vma, addr & SECTION_MASK);
+		flush_tlb_page(vma, (addr & SECTION_MASK)^0x100000);
+	}
+}
+
+static inline int huge_pte_none(pte_t pte)
+{
+	return pte_none(pte);
+}
+
+static inline pte_t huge_pte_wrprotect(pte_t pte)
+{
+	return pte_wrprotect(pte);
+}
+
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+					   unsigned long addr, pte_t *ptep)
+{
+	pte_t old_pte = *ptep;
+	set_huge_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
+}
+
+static inline pte_t huge_ptep_get(pte_t *ptep)
+{
+	return *ptep;
+}
+
+static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
+					     unsigned long addr,
+					     pte_t *ptep, pte_t pte,
+					     int dirty)
+{
+	int changed = !pte_same(huge_ptep_get(ptep), pte);
+	if (changed) {
+		set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+		huge_ptep_clear_flush(vma, addr, &pte);
+	}
+
+	return changed;
+}
+
+static inline int arch_prepare_hugepage(struct page *page)
+{
+	return 0;
+}
+
+static inline void arch_release_hugepage(struct page *page)
+{
+}
+
+#endif /* __ASM_HUGETLB_H */
+
arch/arm/include/asm/page.h +15 -0
index 97b440c..3e6769a 100644
@@ -15,6 +15,21 @@
 #define PAGE_SIZE		(_AC(1,UL) << PAGE_SHIFT)
 #define PAGE_MASK		(~(PAGE_SIZE-1))
 
+#ifdef CONFIG_HUGEPAGE_SIZE_2MB
+/* we have 2MB hugepage for two 1MB section mapping */
+#define HPAGE_SHIFT		(SECTION_SHIFT + 1)
+#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
+#endif
+
+#ifdef CONFIG_HUGEPAGE_SIZE_16MB
+#define HPAGE_SHIFT		SUPERSECTION_SHIFT
+#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
+#endif
+
 #ifndef __ASSEMBLY__
 
 #ifndef CONFIG_MMU
arch/arm/mm/hugetlb.c new file +187 -0

187 lines not on this page · raw message

Signature · 1 line
1.7.1
#2 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

Quoted 17 lines · On Mon, Jan 30, 2012 at 07:57:12AM +0000, bill4carson at gmail.com wrote:
arch/arm/include/asm/hugetlb.h new file +17 -0
+static inline void set_hugepte_section(struct mm_struct *mm, unsigned long addr,
+                                  pte_t *ptep, pte_t pte)
+{
+       pgd_t *pgd;
+       pud_t *pud;
+       pmd_t *pmd;
+
+       int col, row;
+       pte_t **huge_linuxpte = &mm->huge_2m_pte[0];
+
+       row = HUGEPAGE_2M_PTE_ARRAY_ROW(addr);
+       col = HUGEPAGE_2M_PTE_ARRAY_COL(addr);
+
+       /* an valid pte pointer is expected */
+       BUG_ON(huge_linuxpte[row] == 0);
+       BUG_ON(ptep != &huge_linuxpte[row][col]);
+

arch/arm/include/asm/hugetlb.h line 118

Quoted 10 lines
arch/arm/include/asm/hugetlb.h new file +10 -0
+       /* set linux pte first */
+       huge_linuxpte[row][col] = pte;
+
+       /* set hardware pte */
+       pgd = pgd_offset(mm, addr);
+       pud = pud_offset(pgd, addr);
+       pmd = pmd_offset(pud, addr);
+
+       set_hugepte_at(mm, addr, pmd, pte);
+}

I haven't followed the whole structure of your patches but do we need to walk the page tables here? Isn't the ptep the same as the pmd when passed to this function (at least it was with my LPAE implementation).

Signature · 1 line
Catalin
author
#3 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

Quoted 24 lines · Catalin Marinas
Quoted 23 lines · On Mon, Jan 30, 2012 at 07:57:12AM +0000, bill4carson at gmail.com wrote:
arch/arm/include/asm/hugetlb.h new file +23 -0
+static inline void set_hugepte_section(struct mm_struct *mm, unsigned long addr,
+                                  pte_t *ptep, pte_t pte)
+{
+       pgd_t *pgd;
+       pud_t *pud;
+       pmd_t *pmd;
+
+       int col, row;
+       pte_t **huge_linuxpte =&mm->huge_2m_pte[0];
+
+       row = HUGEPAGE_2M_PTE_ARRAY_ROW(addr);
+       col = HUGEPAGE_2M_PTE_ARRAY_COL(addr);
+
+       /* an valid pte pointer is expected */
+       BUG_ON(huge_linuxpte[row] == 0);
+       BUG_ON(ptep !=&huge_linuxpte[row][col]);
+
+       /* set linux pte first */
+       huge_linuxpte[row][col] = pte;
+
+       /* set hardware pte */
+       pgd = pgd_offset(mm, addr);
+       pud = pud_offset(pgd, addr);
Quoted 9 lines

arch/arm/include/asm/hugetlb.h line 118

Quoted 4 lines
arch/arm/include/asm/hugetlb.h new file +4 -0
+       pmd = pmd_offset(pud, addr);
+
+       set_hugepte_at(mm, addr, pmd, pte);
+}

I haven't followed the whole structure of your patches but do we need to walk the page tables here? Isn't the ptep the same as the pmd when passed to this function (at least it was with my LPAE implementation).

Here, ptep is not the same as pmd, mm layer always manages linux pte. For normal page, linux pte and hardware pte is just an 2048 bytes offset away and cpu_v7_set_pte_ext can set both linux/hardware pte easily.

For huge page, linux pte is stored somewhere else,far away from hardware pte table, in set_hugepte_section, "ptep" is the huge page based linux pte address, first set linux pte value "pte" in there; and hardware pmd address could only be derived from "addr" by a page table walk, then setting hardware pmd value in set_hugepte_at, which cpu_v7_set_hugepte_ext does the whole job.

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#4 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

Quoted 38 lines · On Tue, Feb 07, 2012 at 02:00:25AM +0000, bill4carson wrote:
Quoted 24 lines · Catalin Marinas
Quoted 23 lines · On Mon, Jan 30, 2012 at 07:57:12AM +0000, bill4carson at gmail.com wrote:
arch/arm/include/asm/hugetlb.h new file +23 -0
+static inline void set_hugepte_section(struct mm_struct *mm, unsigned long addr,
+                                  pte_t *ptep, pte_t pte)
+{
+       pgd_t *pgd;
+       pud_t *pud;
+       pmd_t *pmd;
+
+       int col, row;
+       pte_t **huge_linuxpte =&mm->huge_2m_pte[0];
+
+       row = HUGEPAGE_2M_PTE_ARRAY_ROW(addr);
+       col = HUGEPAGE_2M_PTE_ARRAY_COL(addr);
+
+       /* an valid pte pointer is expected */
+       BUG_ON(huge_linuxpte[row] == 0);
+       BUG_ON(ptep !=&huge_linuxpte[row][col]);
+
+       /* set linux pte first */
+       huge_linuxpte[row][col] = pte;
+
+       /* set hardware pte */
+       pgd = pgd_offset(mm, addr);
+       pud = pud_offset(pgd, addr);
Quoted 8 lines

arch/arm/include/asm/hugetlb.h line 118

Quoted 4 lines
arch/arm/include/asm/hugetlb.h new file +4 -0
+       pmd = pmd_offset(pud, addr);
+
+       set_hugepte_at(mm, addr, pmd, pte);
+}

I haven't followed the whole structure of your patches but do we need to walk the page tables here? Isn't the ptep the same as the pmd when passed to this function (at least it was with my LPAE implementation).

Here, ptep is not the same as pmd, mm layer always manages linux pte. For normal page, linux pte and hardware pte is just an 2048 bytes offset away and cpu_v7_set_pte_ext can set both linux/hardware pte easily.

Quoted 6 lines

For huge page, linux pte is stored somewhere else,far away from hardware pte table, in set_hugepte_section, "ptep" is the huge page based linux pte address, first set linux pte value "pte" in there; and hardware pmd address could only be derived from "addr" by a page table walk, then setting hardware pmd value in set_hugepte_at, which cpu_v7_set_hugepte_ext does the whole job.

OK. I thought we already have some pointer in the Linux pmd for the actual hardware pmd. Walking the page table isn't expensive in this case, with only 2 levels. For LPAE we don't even need this since we don't have a separate Linux pte/pmd.

Signature · 1 line
Catalin
#5 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

In reply to bill4carson at gmail.com
Quoted 8 lines · On Mon, Jan 30, 2012 at 07:57:12AM +0000, bill4carson at gmail.com wrote:

+/* 2M and 16M hugepage linux ptes are stored in an array
+ *
+ * 2M hugepage
+ * ===========
+ * one linux pte caters to two HW ptes,
+ * so the maximum huge linux pte needed is 4096M/2M = 2048 entry pointers.
+ * Two 4K page is used to store these entry pointers(2048 * 4 = 8192 bytes)
+ * in a two-dimension array, huge_2m_pte[2][1024].

Actually we only need to cover TASK_SIZE so for a 2:2 split you only need half of the above.

Quoted 4 lines

+ *
+ * How to find the hugepage linux pte corresponding to a specific address ?
+ * VA[31] is used as row index;
+ * VA[30:21] is used as column index;

I haven't fully reviewed the code but can we not drop this row/column set up and just use a VA[31:21] as the index?

Quoted 4 lines

+ *
+ * 16M hugepage
+ * ============
+ * one linux pte caters for one HW pte,

Actually that's a bit misleading as we need 16 consecutive pmd entries for a supersection. So one Linux pmd caters for 16 HW pmds.

Quoted 5 lines

+ * so maxium huge linux pte needed is 4096M/16M = 256 entry pointers,
+ * 256 * 4 = 1024 bytes spaces is allocated to store these linux pte;
+ * this is a simple one-dimension array huge_16m_pte[256].
+ *
+ * VA[31:24] is used to index this array;

Maybe we should call them Linux pmd rather than pte in the comments? It is less confusing (I know that the generic hugetlb code calls them ptes).

Signature · 1 line
Catalin
author
#6 lore raw

PATCH 1/7 Add various hugetlb arm high level hooks

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 12 lines · On Mon, Jan 30, 2012 at 07:57:12AM +0000, bill4carson at gmail.com wrote:
Quoted 10 lines

+/* 2M and 16M hugepage linux ptes are stored in an array
+ *
+ * 2M hugepage
+ * ===========
+ * one linux pte caters to two HW ptes,
+ * so the maximum huge linux pte needed is 4096M/2M = 2048 entry pointers.
+ * Two 4K page is used to store these entry pointers(2048 * 4 = 8192 bytes)
+ * in a two-dimension array, huge_2m_pte[2][1024].

Quoted 2 lines

Actually we only need to cover TASK_SIZE so for a 2:2 split you only need half of the above.

I haven't polish here yet.
Yes, to be precise, this array depends on TASK_SIZE configuration. The maximum array size is 1536 when TASK_SIZE is 0xc0000000 then kmalloc instead of __get_free_page can be used to allocate 1536 * sizeof(pte_t *). In this way VA[31:21] could be used as index to get rid of row/column stuff.

I will keep this on V2 todo list :)

Quoted 9 lines
Quoted 6 lines

+ *
+ * How to find the hugepage linux pte corresponding to a specific address ?
+ * VA[31] is used as row index;
+ * VA[30:21] is used as column index;

I haven't fully reviewed the code but can we not drop this row/column set up and just use a VA[31:21] as the index?

Please see above reply.

Quoted 8 lines
Quoted 5 lines

+ *
+ * 16M hugepage
+ * ============
+ * one linux pte caters for one HW pte,

Actually that's a bit misleading as we need 16 consecutive pmd entries for a supersection. So one Linux pmd caters for 16 HW pmds.

You are right, I will correct this in V2.

Quoted 10 lines
Quoted 6 lines

+ * so maxium huge linux pte needed is 4096M/16M = 256 entry pointers,
+ * 256 * 4 = 1024 bytes spaces is allocated to store these linux pte;
+ * this is a simple one-dimension array huge_16m_pte[256].
+ *
+ * VA[31:24] is used to index this array;

Maybe we should call them Linux pmd rather than pte in the comments? It is less confusing (I know that the generic hugetlb code calls them ptes).

OK, I will correct this in V2.

Quoted 4 lines

--
Catalin

author
#7 lore raw

PATCH 2/7 Add various hugetlb page table fix

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

- Add L_PTE_huge page to mark huge page
- Modify pte_pfn for hugetlb
- Add set_hugepte_at for hugetlb arm high levle hooks use

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/include/asm/pgtable-2level.h |    8 ++++++++
 arch/arm/include/asm/pgtable.h        |   28 ++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)
arch/arm/include/asm/pgtable-2level.h +8 -0
index 2317a71..062c93c 100644
@@ -123,6 +123,11 @@
 #define L_PTE_USER		(_AT(pteval_t, 1) << 8)
 #define L_PTE_XN		(_AT(pteval_t, 1) << 9)
 #define L_PTE_SHARED		(_AT(pteval_t, 1) << 10)	/* shared(v6), coherent(xsc3) */
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE	(_AT(pteval_t, 1) << 11) /* mark hugepage */
+#define L_PTE_HPAGE_2M  (_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */
+#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */
+#endif
 
 /*
  * These are the memory types, defined to be compatible with

@@ -178,6 +183,9 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
 #define pmd_addr_end(addr,end) (end)
 
 #define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext)
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define set_hugepte_ext(ptep,pte,ext) cpu_set_hugepte_ext(ptep,pte,ext)
+#endif
 
 #endif /* __ASSEMBLY__ */
arch/arm/include/asm/pgtable.h +28 -0
index f66626d..da875d8 100644
@@ -187,7 +187,21 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
 #define pte_offset_map(pmd,addr)	(__pte_map(pmd) + pte_index(addr))
 #define pte_unmap(pte)			__pte_unmap(pte)
 
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+
+#ifdef CONFIG_HUGEPAGE_SIZE_2MB
+#define hugepte_pfn(pte)    ((pte_val(pte) & SECTION_MASK) >> PAGE_SHIFT)
+#endif
+#ifdef CONFIG_HUGEPAGE_SIZE_16MB
+#define hugepte_pfn(pte)    ((pte_val(pte) & SUPERSECTION_MASK) >> PAGE_SHIFT)
+#endif
+#define pte_is_huge(pte)	(pte_val(pte) & L_PTE_HUGEPAGE)
+#define pte_pfn(pte)	    (pte_is_huge(pte) ? \
+				hugepte_pfn(pte) : ((pte_val(pte) & PHYS_MASK) >> PAGE_SHIFT))
+#else
 #define pte_pfn(pte)		((pte_val(pte) & PHYS_MASK) >> PAGE_SHIFT)
+#endif /*!CONFIG_ARM_HUGETLB_SUPPORT*/
+
 #define pfn_pte(pfn,prot)	__pte(__pfn_to_phys(pfn) | pgprot_val(prot))
 
 #define pte_page(pte)		pfn_to_page(pte_pfn(pte))

@@ -213,6 +227,14 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
 		set_pte_ext(ptep, pteval, PTE_EXT_NG);
 	}
 }
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+static inline void set_hugepte_at(struct mm_struct *mm, unsigned long addr,
+			      pte_t *ptep, pte_t pteval)
+{
+	__sync_icache_dcache(pteval);
+	set_hugepte_ext(ptep, pteval, PTE_EXT_NG);
+}
+#endif
 
 #define pte_none(pte)		(!pte_val(pte))
 #define pte_present(pte)	(pte_val(pte) & L_PTE_PRESENT)

@@ -235,6 +257,12 @@ PTE_BIT_FUNC(mkclean,   &= ~L_PTE_DIRTY);
 PTE_BIT_FUNC(mkdirty,   |= L_PTE_DIRTY);
 PTE_BIT_FUNC(mkold,     &= ~L_PTE_YOUNG);
 PTE_BIT_FUNC(mkyoung,   |= L_PTE_YOUNG);
+#ifdef CONFIG_HUGEPAGE_SIZE_2MB
+PTE_BIT_FUNC(mkhuge,    |= L_PTE_HUGEPAGE | L_PTE_HPAGE_2M);
+#endif
+#ifdef CONFIG_HUGEPAGE_SIZE_16MB
+PTE_BIT_FUNC(mkhuge,    |= L_PTE_HUGEPAGE | L_PTE_HPAGE_16M);
+#endif
 
 static inline pte_t pte_mkspecial(pte_t pte) { return pte; }
Signature · 1 line
1.7.1
#8 lore raw

PATCH 2/7 Add various hugetlb page table fix

arch/arm/include/asm/pgtable-2level.h line 127

Quoted 10 lines · On 30 January 2012 07:57, <[email protected]> wrote:
arch/arm/include/asm/pgtable-2level.h +0 -0
index 2317a71..062c93c 100644
@@ -123,6 +123,11 @@
 ?#define L_PTE_USER ? ? ? ? ? ? (_AT(pteval_t, 1) << 8)
 ?#define L_PTE_XN ? ? ? ? ? ? ? (_AT(pteval_t, 1) << 9)

?#define L_PTE_SHARED ? ? ? ? ? (_AT(pteval_t, 1) << 10) ? ? ? ?/* shared(v6), coherent(xsc3) */

arch/arm/include/asm/pgtable-2level.h +2 -0
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE (_AT(pteval_t, 1) << 11) /* mark hugepage */

Do we actually need this bit? The checks are done starting from the top pgd/pud/pmd. So we stop at the pmd level and check whether it is table or a section mapping. I don't think we ever check a pte entry for whether it is huge or not (as,@least with the implementation you posted, it does not support 64K pages).

arch/arm/include/asm/pgtable-2level.h

Quoted 2 lines
arch/arm/include/asm/pgtable-2level.h +2 -0
+#define L_PTE_HPAGE_2M ?(_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */
+#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */

If we go for 2MB only, we can ignore both definitions here.

Signature · 1 line
Catalin
#9 lore raw

PATCH 2/7 Add various hugetlb page table fix

In reply to bill4carson at gmail.com

arch/arm/include/asm/pgtable-2level.h line 130

Quoted 13 lines · On Mon, Jan 30, 2012 at 03:57:13PM +0800, bill4carson at gmail.com wrote:
arch/arm/include/asm/pgtable-2level.h +5 -0
index 2317a71..062c93c 100644
@@ -123,6 +123,11 @@
 #define L_PTE_USER		(_AT(pteval_t, 1) << 8)
 #define L_PTE_XN		(_AT(pteval_t, 1) << 9)
 #define L_PTE_SHARED		(_AT(pteval_t, 1) << 10)	/* shared(v6), coherent(xsc3) */
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE	(_AT(pteval_t, 1) << 11) /* mark hugepage */
+#define L_PTE_HPAGE_2M  (_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */
+#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */
+#endif

(1) How does this work when normal pages can have bit 11 set if they're an odd PFN?

(2) How do we even get to PTE level when a 2 or 16MB section doesn't have a pte table (as the L1 entry is used for the section or supersection mapping) ?

#10 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 17 lines · Russell King - ARM Linux

arch/arm/include/asm/pgtable-2level.h line 130

Quoted 13 lines · On Mon, Jan 30, 2012 at 03:57:13PM +0800, bill4carson at gmail.com wrote:
arch/arm/include/asm/pgtable-2level.h +0 -0
index 2317a71..062c93c 100644
@@ -123,6 +123,11 @@
 ?#define L_PTE_USER ? ? ? ? ? (_AT(pteval_t, 1) << 8)
 ?#define L_PTE_XN ? ? ? ? ? ? (_AT(pteval_t, 1) << 9)

?#define L_PTE_SHARED ? ? ? ? (_AT(pteval_t, 1) << 10) ? ? ? ?/* shared(v6), coherent(xsc3) */

arch/arm/include/asm/pgtable-2level.h +5 -0
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE ? ? ? (_AT(pteval_t, 1) << 11) /* mark hugepage */
+#define L_PTE_HPAGE_2M ?(_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */
+#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */
+#endif

(1) How does this work when normal pages can have bit 11 set if they're an odd PFN?

Isn't that bit 12?

Quoted 3 lines

(2) How do we even get to PTE level when a 2 or 16MB section doesn't have a pte table (as the L1 entry is used for the section or supersection mapping) ?

We don't, that's why I think we don't even need this bit defined.

Signature · 1 line
Catalin
author
#11 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 18 lines · Catalin Marinas
Quoted 16 lines · Russell King - ARM Linux

arch/arm/include/asm/pgtable-2level.h line 130

Quoted 13 lines · On Mon, Jan 30, 2012 at 03:57:13PM +0800, bill4carson at gmail.com wrote:
arch/arm/include/asm/pgtable-2level.h +5 -0
index 2317a71..062c93c 100644
@@ -123,6 +123,11 @@
  #define L_PTE_USER           (_AT(pteval_t, 1)<<  8)
  #define L_PTE_XN             (_AT(pteval_t, 1)<<  9)
  #define L_PTE_SHARED         (_AT(pteval_t, 1)<<  10)        /* shared(v6), coherent(xsc3) */
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE       (_AT(pteval_t, 1)<<  11) /* mark hugepage */
+#define L_PTE_HPAGE_2M  (_AT(pteval_t, 1)<<  12) /* only when HUGEPAGE set */
+#define L_PTE_HPAGE_16M (_AT(pteval_t, 1)<<  13) /* only when HUGEPAGE set */
+#endif

(1) How does this work when normal pages can have bit 11 set if they're an odd PFN?

Quoted 7 lines

Isn't that bit 12?

Quoted 3 lines

(2) How do we even get to PTE level when a 2 or 16MB section doesn't have a pte table (as the L1 entry is used for the section or supersection mapping) ?

We don't, that's why I think we don't even need this bit defined.

First, thanks for Russel/Catalin to take time review this patch:)

a:
By pte used in here, I mean linux pte. linux pte is needed by generic mm layer
whether this mapping is 4K, 1MB or 16MB.

b:
Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from
a given pte, and pte_pfn is used first to convert pte into a page frame number.
This is where need to be careful. Normal page based pte upper [31:12] bits is pfn,
huge page(1MB) based pte upper[31:20] is pfn, so one bit MUST distinguish normal
page based pte with huge page based pte.

This one bit will *only* be BIT11, one last unused PTE flag within normal page.
that's why L_PTE_HUGEPAGE is defined.

If L_PTE_HUGEPAGE is set, then BIT19:12 is enough to be used to mark this pte is 1MB
or 16MB huge page.

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#12 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 5 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from a given pte, and pte_pfn is used first to convert pte into a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn? I haven't seen any other architecture doing shifts other than PAGE_SHIFT even for huge pages.

Signature · 1 line
Catalin
author
#13 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 9 lines · Catalin Marinas
Quoted 5 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from a given pte, and pte_pfn is used first to convert pte into a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn?

Hello, Catalin

Let me take a few words to make this clear for us.

pte_page is defined as following to derive page struct from a given pte. This macro is used both in generic mm as well as hugetlb sub-system, so we need do the switch in pte_pfn to mark huge page based linux pte out of normal page based linux pte, that's what L_PTE_HUGEPAGE for.

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

So L_PTE_HUGEPAGE is *NOT* set in normal page based linux pte, linux pte bits[31:12] is the page frame number;
otherwise, we got a huge page based linux pte, and linux pte bits[31:20] is page frame number for SECTION mapping, and bits[31:24] is page frame number for SUPER-SECTION mapping.

I think this the full story of following code:

#ifdef CONFIG_ARM_HUGETLB_SUPPORT

#ifdef CONFIG_HUGEPAGE_SIZE_2MB
#define hugepte_pfn(pte) ((pte_val(pte) & SECTION_MASK) >> PAGE_SHIFT)
#endif
#ifdef CONFIG_HUGEPAGE_SIZE_16MB
#define hugepte_pfn(pte) ((pte_val(pte) & SUPERSECTION_MASK) >>
PAGE_SHIFT)
#endif
#define pte_is_huge(pte) (pte_val(pte) & L_PTE_HUGEPAGE)

#define pte_pfn(pte)	    (pte_is_huge(pte) ? \
				hugepte_pfn(pte) : ((pte_val(pte) & PHYS_MASK) >> PAGE_SHIFT))

#else
#define pte_pfn(pte) ((pte_val(pte) & PHYS_MASK) >> PAGE_SHIFT)
#endif /*!CONFIG_ARM_HUGETLB_SUPPORT*/

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

Quoted 3 lines

I haven't seen any other architecture doing
shifts other than PAGE_SHIFT even for huge pages.

#define L_PTE_HUGEPAGE (_AT(pteval_t, 1) << 11) /* mark hugepage */
#define L_PTE_HPAGE_2M (_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */
#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */

See linux pte BIT12 is used to denote 2MB huge page, BIT13 is used for 16MB page, that's why PAGE_SHIFT is not enough for do the shifting.

I hope I understand your question and give the right answer :)

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#14 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 10 lines · On Tue, Feb 07, 2012 at 01:42:01AM +0000, bill4carson wrote:
Quoted 9 lines · Catalin Marinas
Quoted 5 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from a given pte, and pte_pfn is used first to convert pte into a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn?

...

Quoted 9 lines

pte_page is defined as following to derive page struct from a given pte. This macro is used both in generic mm as well as hugetlb sub-system, so we need do the switch in pte_pfn to mark huge page based linux pte out of normal page based linux pte, that's what L_PTE_HUGEPAGE for.

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

So L_PTE_HUGEPAGE is *NOT* set in normal page based linux pte, linux pte bits[31:12] is the page frame number;

I agree.

Quoted 3 lines

otherwise, we got a huge page based linux pte, and linux pte bits[31:20] is page frame number for SECTION mapping, and bits[31:24] is page frame number for SUPER-SECTION mapping.

Actually it is still 31:12 but with bits 19:12 or 23:12 masked out. So you do the correct shift by PAGE_SHIFT with the additional masking for huge pages (harmless).

But do we actually need this masking? Do the huge_pte_offset() or huge_pte_alloc() functions return the Linux pte (pmd) for the huge page? If yes, can we not ensure that bits 19:12 are already zero? This shouldn't be any different from the 4K Linux pte but with an address aligned to 1MB.

Signature · 1 line
Catalin
author
#15 lore raw

PATCH 2/7 Add various hugetlb page table fix

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 32 lines · On Tue, Feb 07, 2012 at 01:42:01AM +0000, bill4carson wrote:
Quoted 10 lines · Catalin Marinas
Quoted 9 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:
Quoted 5 lines

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from a given pte, and pte_pfn is used first to convert pte into a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn?

...

Quoted 9 lines

pte_page is defined as following to derive page struct from a given pte. This macro is used both in generic mm as well as hugetlb sub-system, so we need do the switch in pte_pfn to mark huge page based linux pte out of normal page based linux pte, that's what L_PTE_HUGEPAGE for.

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

So L_PTE_HUGEPAGE is *NOT* set in normal page based linux pte, linux pte bits[31:12] is the page frame number;

I agree.

Quoted 3 lines

otherwise, we got a huge page based linux pte, and linux pte bits[31:20] is page frame number for SECTION mapping, and bits[31:24] is page frame number for SUPER-SECTION mapping.

Actually it is still 31:12 but with bits 19:12 or 23:12 masked out. So you do the correct shift by PAGE_SHIFT with the additional masking for huge pages (harmless).

Quoted 6 lines

But do we actually need this masking? Do the huge_pte_offset() or huge_pte_alloc() functions return the Linux pte (pmd) for the huge page? If yes, can we not ensure that bits 19:12 are already zero? This shouldn't be any different from the 4K Linux pte but with an address aligned to 1MB.

I'm afraid there is some misunderstanding. huge_pte_offset() returns the huge linux pte address if they exist; huge_pte_alloc() allocates a location to store huge linux pte, and return this address;
non of above functions return huge linux pte *value*.

make_huge_pte() will return huge linux pte for a given page and vma protection bits,
please notice pte_mkhuge is used to mark this pte as huge linux pte by setting L_PTE_HUGEPAGE, then set_huge_pte_at() is used to set huge linux pte as well huge hardware pte.

2113static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
2114 int writable)
2115{
2116 pte_t entry;
2117
2118 if (writable) {
2119 entry =
2120 pte_mkwrite(pte_mkdirty(mk_pte(page,
vma->vm_page_prot)));
2121 } else {
2122 entry = huge_pte_wrprotect(mk_pte(page, vma->vm_page_prot));

2123        }
2124        entry = pte_mkyoung(entry);
2125        entry = pte_mkhuge(entry);

2126
2127 return entry;
2128}

Hence, normal linux pte must has L_PTE_HUGEPAE cleared;
A huge linux pte must has L_PTE_HUGEPAGE(BIT11) set
This could lead to L_PTE_HPAGE_2M(BIT12) or L_PTE_HPAGE_16M(BIT13) set respectively, that's why the masking is needed for pte_pfn.

+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define L_PTE_HUGEPAGE (_AT(pteval_t, 1) << 11) /* mark hugepage */
+#define L_PTE_HPAGE_2M (_AT(pteval_t, 1) << 12) /* only when HUGEPAGE set */ +#define L_PTE_HPAGE_16M (_AT(pteval_t, 1) << 13) /* only when HUGEPAGE set */ +#endif

Quoted 3 lines

--
Catalin

#16 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 39 lines · carson bill

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 32 lines · On Tue, Feb 07, 2012 at 01:42:01AM +0000, bill4carson wrote:
Quoted 10 lines · Catalin Marinas
Quoted 9 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:
Quoted 5 lines

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page struct from a given pte, and pte_pfn is used first to convert pte into a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn?

...

Quoted 9 lines

pte_page is defined as following to derive page struct from a given pte. This macro is used both in generic mm as well as hugetlb sub-system, so we need do the switch in pte_pfn to mark huge page based linux pte out of normal page based linux pte, that's what L_PTE_HUGEPAGE for.

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

So L_PTE_HUGEPAGE is *NOT* set in normal page based linux pte, linux pte bits[31:12] is the page frame number;

I agree.

Quoted 3 lines

otherwise, we got a huge page based linux pte, and linux pte bits[31:20] is page frame number for SECTION mapping, and bits[31:24] is page frame number for SUPER-SECTION mapping.

Actually it is still 31:12 but with bits 19:12 or 23:12 masked out. So you do the correct shift by PAGE_SHIFT with the additional masking for huge pages (harmless).

Quoted 5 lines

But do we actually need this masking? Do the huge_pte_offset() or huge_pte_alloc() functions return the Linux pte (pmd) for the huge page? If yes, can we not ensure that bits 19:12 are already zero? This shouldn't be any different from the 4K Linux pte but with an address aligned to 1MB.

Quoted 5 lines

I'm afraid there is some misunderstanding. huge_pte_offset() returns the huge linux pte address if they exist; huge_pte_alloc() allocates a location to store huge linux pte, and return this address;
non of above functions return huge linux pte *value*.

I agree, huge_pte_offset() returns a pointer to the Linux pte/pmd if it exists. My point is that the values stored in Linux pte/pmd have bits 20:12 cleared already as the address is at least 2MB aligned (well, apart from the additional L_PTE_HPAGE_* bits that you declared). Is this correct? If yes, then you don't need any additional masking for pte_pfn() even if it is passed a Linux pmd.

Quoted 21 lines

make_huge_pte() will return huge linux pte for a given page and vma protection bits,
please notice pte_mkhuge is used to mark this pte as huge linux pte by setting L_PTE_HUGEPAGE, then set_huge_pte_at() is used to set huge linux pte as well huge hardware pte.

2113static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
2114 int writable)
2115{
2116 pte_t entry;
2117
2118 if (writable) {
2119 entry =
2120 pte_mkwrite(pte_mkdirty(mk_pte(page,
vma->vm_page_prot)));
2121 } else {
2122 entry = huge_pte_wrprotect(mk_pte(page, vma->vm_page_prot));

2123        }
2124        entry = pte_mkyoung(entry);
2125        entry = pte_mkhuge(entry);
Quoted 8 lines

2126
2127 return entry;
2128}

Hence, normal linux pte must has L_PTE_HUGEPAE cleared;
A huge linux pte must has L_PTE_HUGEPAGE(BIT11) set
This could lead to L_PTE_HPAGE_2M(BIT12) or L_PTE_HPAGE_16M(BIT13) set respectively, that's why the masking is needed for pte_pfn.

But if you avoid setting L_PTE_HPAGE_*, than we don't need the masking for pte_pfn. In which case, we don't need to differentiate between a normal and a huge pte in pte_pfn(), so no need for L_PTE_HUGEPAGE. The set_huge_pte_at() function is only called with a huge pte, so it doesn't need to check the L_PTE_HUGEPAGE bit either.

Signature · 1 line
Catalin
author
#17 lore raw

PATCH 2/7 Add various hugetlb page table fix

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 49 lines · carson bill
Quoted 42 lines

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 35 lines · On Tue, Feb 07, 2012 at 01:42:01AM +0000, bill4carson wrote:
Quoted 12 lines · Catalin Marinas
Quoted 11 lines · On Wed, Feb 01, 2012 at 03:10:21AM +0000, bill4carson wrote:
Quoted 7 lines

Why L_PTE_HUGEPAGE is needed?

hugetlb subsystem will call pte_page to derive the corresponding page
struct from a given pte, and pte_pfn is used first to convert pte into
a page frame number.

Are you sure the pte_pfn() conversion is right? Does it need to be different from the 4K pfn?

...

Quoted 10 lines

pte_page is defined as following to derive page struct from a given pte.
This macro is used both in generic mm as well as hugetlb sub-system, so we need do the switch in pte_pfn to mark huge page based linux pte out of normal page based linux pte, that's what L_PTE_HUGEPAGE for.

#define pte_page(pte) pfn_to_page(pte_pfn(pte))

So L_PTE_HUGEPAGE is *NOT* set in normal page based linux pte, linux pte bits[31:12] is the page frame number;

I agree.

Quoted 3 lines

otherwise, we got a huge page based linux pte, and linux pte bits[31:20] is page frame number for SECTION mapping, and bits[31:24] is page frame number for SUPER-SECTION mapping.

Actually it is still 31:12 but with bits 19:12 or 23:12 masked out. So you do the correct shift by PAGE_SHIFT with the additional masking for huge pages (harmless).

Quoted 5 lines

But do we actually need this masking? Do the huge_pte_offset() or huge_pte_alloc() functions return the Linux pte (pmd) for the huge page? If yes, can we not ensure that bits 19:12 are already zero? This shouldn't be any different from the 4K Linux pte but with an address aligned to 1MB.

Quoted 5 lines

I'm afraid there is some misunderstanding. huge_pte_offset() returns the huge linux pte address if they exist; huge_pte_alloc() allocates a location to store huge linux pte, and return this address;
non of above functions return huge linux pte *value*.

Quoted 6 lines

I agree, huge_pte_offset() returns a pointer to the Linux pte/pmd if it exists. My point is that the values stored in Linux pte/pmd have bits 20:12 cleared already as the address is at least 2MB aligned (well, apart from the additional L_PTE_HPAGE_* bits that you declared). Is this correct? If yes, then you don't need any additional masking for pte_pfn() even if it is passed a Linux pmd.

Yes, pte_pfn doesn't need any modification if we don't need any L_PTE_HPAGE_*).

Quoted 35 lines
Quoted 26 lines

make_huge_pte() will return huge linux pte for a given page and vma protection bits,
please notice pte_mkhuge is used to mark this pte as huge linux pte by setting
L_PTE_HUGEPAGE, then set_huge_pte_at() is used to set huge linux pte as well
huge hardware pte.

2113static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
2114 int writable)
2115{
2116 pte_t entry;
2117
2118 if (writable) {
2119 entry =
2120 pte_mkwrite(pte_mkdirty(mk_pte(page,
vma->vm_page_prot)));
2121 } else {
2122 entry = huge_pte_wrprotect(mk_pte(page,
vma->vm_page_prot));

2123        }
2124        entry = pte_mkyoung(entry);
2125        entry = pte_mkhuge(entry);
Quoted 8 lines

2126
2127 return entry;
2128}

Hence, normal linux pte must has L_PTE_HUGEPAE cleared;
A huge linux pte must has L_PTE_HUGEPAGE(BIT11) set
This could lead to L_PTE_HPAGE_2M(BIT12) or L_PTE_HPAGE_16M(BIT13) set respectively, that's why the masking is needed for pte_pfn.

Quoted 6 lines

But if you avoid setting L_PTE_HPAGE_*, than we don't need the masking for pte_pfn. In which case, we don't need to differentiate between a normal and a huge pte in pte_pfn(), so no need for L_PTE_HUGEPAGE. The set_huge_pte_at() function is only called with a huge pte, so it doesn't need to check the L_PTE_HUGEPAGE bit either.

I understood what you mean now, and the original design is almost like you said. But the consequences of eliminating L_PTE_HUGEPAGE as well as L_PTE_HPAGE_* only leave us with huge page size fixed at build time, I mean boot time huge page
size configuration feature like X86 will NOT be feasible anymore!

looks like we have to made a choice now, what do you think? Catalin

Quoted 3 lines

--
Catalin

#18 lore raw

PATCH 2/7 Add various hugetlb page table fix

Quoted 7 lines · carson bill

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 5 lines

But if you avoid setting L_PTE_HPAGE_*, than we don't need the masking for pte_pfn. In which case, we don't need to differentiate between a normal and a huge pte in pte_pfn(), so no need for L_PTE_HUGEPAGE. The set_huge_pte_at() function is only called with a huge pte, so it doesn't need to check the L_PTE_HUGEPAGE bit either.

Quoted 5 lines

I understood what you mean now, and the original design is almost like you said. But the consequences of eliminating L_PTE_HUGEPAGE as well as L_PTE_HPAGE_* only leave us with huge page size fixed at build time, I mean boot time huge page size configuration feature like X86 will NOT be feasible anymore!

Yes it will :). Just store the page size in some variable that you check at run-time. We won't support mixed huge page sizes though.

Signature · 1 line
Catalin
author
#19 lore raw

PATCH 2/7 Add various hugetlb page table fix

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 8 lines · carson bill
Quoted 7 lines

2012/2/7, Catalin Marinas <[email protected]>:

Quoted 5 lines

But if you avoid setting L_PTE_HPAGE_*, than we don't need the masking for pte_pfn. In which case, we don't need to differentiate between a normal and a huge pte in pte_pfn(), so no need for L_PTE_HUGEPAGE. The set_huge_pte_at() function is only called with a huge pte, so it doesn't need to check the L_PTE_HUGEPAGE bit either.

Quoted 9 lines
Quoted 5 lines

I understood what you mean now, and the original design is almost like you said. But the consequences of eliminating L_PTE_HUGEPAGE as well as L_PTE_HPAGE_* only leave us with huge page size fixed at build time, I mean boot time huge page size configuration feature like X86 will NOT be feasible anymore!

Yes it will :). Just store the page size in some variable that you check at run-time. We won't support mixed huge page sizes though.

Got it:)
Please review the other parts of patch, let me know if any question arises.

Quoted 3 lines

--
Catalin

author
#20 lore raw

PATCH 3/7 Introduce set_hugepte_ext api for huge page hardware page table setup

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

All hugetlb arm high level hooks eventually call this api using set_hugepte_at

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/include/asm/glue-proc.h |    3 +
 arch/arm/include/asm/proc-fns.h  |    3 +
 arch/arm/mm/proc-v7-2level.S     |   96 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)
arch/arm/include/asm/glue-proc.h +3 -0
index e2be7f1..2bbd452 100644
@@ -256,6 +256,9 @@
 #define cpu_dcache_clean_area		__glue(CPU_NAME,_dcache_clean_area)
 #define cpu_do_switch_mm		__glue(CPU_NAME,_switch_mm)
 #define cpu_set_pte_ext			__glue(CPU_NAME,_set_pte_ext)
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define cpu_set_hugepte_ext		__glue(CPU_NAME,_set_hugepte_ext)
+#endif
 #define cpu_suspend_size		__glue(CPU_NAME,_suspend_size)
 #define cpu_do_suspend			__glue(CPU_NAME,_do_suspend)
 #define cpu_do_resume			__glue(CPU_NAME,_do_resume)
arch/arm/include/asm/proc-fns.h +3 -0
index f3628fb..75bd755 100644
@@ -87,6 +87,9 @@ extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
 extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte);
 #else
 extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+extern void cpu_set_hugepte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
+#endif
 #endif
 extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
arch/arm/mm/proc-v7-2level.S +96 -0

102 lines not on this page · raw message

Signature · 1 line
1.7.1
author
#21 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

One easy way to store huge page linux pte is mm_struct instead of thread_info that's because when parent task with huge page VMA calls fork, parent huge page pagetable entries are copied into child pagetable. This is done in

int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)

We cannot derive child's thread_info just using struct mm_struct *dst. if we have struct mm_struct **dst, then it's easy to find the corresponding task_struct as well as thread_info, but we only get struct mm_struct *dst. It's possible to find the desired task_struct by iterating the global task list by comparing task_struct->mm with dst.
So mm_struct is used for huge page linux pte for faster lookup and efficient.

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/mm/pgd.c        |   28 ++++++++++++++++++++++++++++
 include/linux/mm_types.h |   11 +++++++++++
 2 files changed, 39 insertions(+), 0 deletions(-)
arch/arm/mm/pgd.c +28 -0
index a3e78cc..b04a69a 100644
@@ -91,6 +91,14 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
 		pte_unmap(new_pte);
 	}
 
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+	/* reset the hugepage linux pte pointer
+	 * for new mm_struct when we do the fork
+	 */
+	mm->huge_2m_pte[HUGE_2M_PTE_1ST_ARRAY] = 0;
+	mm->huge_2m_pte[HUGE_2M_PTE_2ND_ARRAY] = 0;
+	mm->huge_16m_pte   = 0;
+#endif
 	return new_pgd;
 
 no_pte:

@@ -103,6 +111,25 @@ no_pgd:
 	return NULL;
 }
 
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+static void free_huge_linuxpte(struct mm_struct *mm)
+{
+	pte_t **huge_linuxpte = &mm->huge_2m_pte[0];
+	int i;
+
+	for (i = 0; i < HUGE_2M_PTE_SIZE; i++)
+		if (huge_linuxpte[i] != 0)
+			free_page((unsigned long)huge_linuxpte[i]);
+
+	if (mm->huge_16m_pte != NULL)
+		kfree(mm->huge_16m_pte);
+}
+#else
+static void free_huge_linuxpte(struct mm_struct *mm)
+{
+}
+#endif
+
 void pgd_free(struct mm_struct *mm, pgd_t *pgd_base)
 {
 	pgd_t *pgd;

@@ -135,6 +162,7 @@ no_pud:
 	pgd_clear(pgd);
 	pud_free(mm, pud);
 no_pgd:
+	free_huge_linuxpte(mm);
 #ifdef CONFIG_ARM_LPAE
 	/*
 	 * Free modules/pkmap or identity pmd tables.
include/linux/mm_types.h +11 -0
index 3cc3062..88f76e6 100644
@@ -23,6 +23,11 @@
 struct address_space;
 
 #define USE_SPLIT_PTLOCKS	(NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS)
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define HUGE_2M_PTE_SIZE      2
+#define HUGE_2M_PTE_1ST_ARRAY 0
+#define HUGE_2M_PTE_2ND_ARRAY 1
+#endif
 
 /*
  * Each physical page in the system has a struct page associated with

@@ -388,6 +393,12 @@ struct mm_struct {
 #ifdef CONFIG_CPUMASK_OFFSTACK
 	struct cpumask cpumask_allocation;
 #endif
+
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+	/* we place hugepage linux pte at mm_struct  */
+	pte_t *huge_2m_pte[HUGE_2M_PTE_SIZE];
+	pte_t *huge_16m_pte;
+#endif
 };
 
 static inline void mm_init_cpumask(struct mm_struct *mm)
Signature · 1 line
1.7.1
#22 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

Quoted 28 lines · On 30 January 2012 07:57, <[email protected]> wrote:
include/linux/mm_types.h +5 -0
index 3cc3062..88f76e6 100644
@@ -23,6 +23,11 @@
 ?struct address_space;
 
 ?#define USE_SPLIT_PTLOCKS ? ? ?(NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS)
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+#define HUGE_2M_PTE_SIZE ? ? ?2
+#define HUGE_2M_PTE_1ST_ARRAY 0
+#define HUGE_2M_PTE_2ND_ARRAY 1
+#endif

?/*
?* Each physical page in the system has a struct page associated with

include/linux/mm_types.h +0 -0
@@ -388,6 +393,12 @@ struct mm_struct {

?#ifdef CONFIG_CPUMASK_OFFSTACK
? ? ? ?struct cpumask cpumask_allocation;
?#endif

include/linux/mm_types.h +6 -0
+
+#ifdef CONFIG_ARM_HUGETLB_SUPPORT
+ ? ? ? /* we place hugepage linux pte at mm_struct ?*/
+ ? ? ? pte_t *huge_2m_pte[HUGE_2M_PTE_SIZE];
+ ? ? ? pte_t *huge_16m_pte;
+#endif

?};

Quoted 1 line

?static inline void mm_init_cpumask(struct mm_struct *mm)

Please don't touch generic code. There is mm_context_t defined in arch/arm/include/asm/mmu.h, just add the stuff you need there.

Signature · 1 line
Catalin
#23 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

In reply to bill4carson at gmail.com
Quoted 9 lines · On Mon, Jan 30, 2012 at 03:57:15PM +0800, bill4carson at gmail.com wrote:

From: Bill Carson <[email protected]>

One easy way to store huge page linux pte is mm_struct instead of thread_info that's because when parent task with huge page VMA calls fork, parent huge page pagetable entries are copied into child pagetable. This is done in

int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)

Quoted 6 lines

We cannot derive child's thread_info just using struct mm_struct *dst. if we have struct mm_struct **dst, then it's easy to find the corresponding task_struct as well as thread_info, but we only get struct mm_struct *dst. It's possible to find the desired task_struct by iterating the global task list by comparing task_struct->mm with dst.
So mm_struct is used for huge page linux pte for faster lookup and efficient.

I really do not understand this description, and it doesn't seem to tie up with the code. What problem are you trying to solve here?

Note that a mm_struct can be shared between multiple task_structs, so if your thinking is that something in the mm_struct or page table needs to know about a task_struct, you're ideas are wrong.

author
#24 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

Quoted 16 lines · Russell King - ARM Linux
Quoted 9 lines · On Mon, Jan 30, 2012 at 03:57:15PM +0800, bill4carson at gmail.com wrote:

From: Bill Carson<[email protected]>

One easy way to store huge page linux pte is mm_struct instead of thread_info that's because when parent task with huge page VMA calls fork, parent huge page pagetable entries are copied into child pagetable. This is done in

int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)

Quoted 6 lines

We cannot derive child's thread_info just using struct mm_struct *dst. if we have struct mm_struct **dst, then it's easy to find the corresponding task_struct as well as thread_info, but we only get struct mm_struct *dst. It's possible to find the desired task_struct by iterating the global task list by comparing task_struct->mm with dst.
So mm_struct is used for huge page linux pte for faster lookup and efficient.

Quoted 7 lines

I really do not understand this description, and it doesn't seem to tie up with the code. What problem are you trying to solve here?

Note that a mm_struct can be shared between multiple task_structs, so if your thinking is that something in the mm_struct or page table needs to know about a task_struct, you're ideas are wrong.

Normal page based pte has hardware version and linux version, these two kinds of
ptes occupy half of 4K page, and each of two pmd level entry pointer to this half 4K
page.

For huge page, mappings only exist in pmd level from hardware perspective, however
mm subsystem also needs to know the linux version *pte* of this huge page based
mapping, problems is where to store these huge page linux pte?

A:
Store huge page linux pte in mm_struct

B:
Store huge page linux pte in mm_context_t suggested by Catalin. This is almost like option A, while it's nice to modify arm code only and take small effort to make it happen.

C:
Modify pgd_alloc to allocate 2048 pgd_t entries plus two void pointers Use these two additional pointers to store huge page linux pte. It's feasible, but I don't know whether this is a good idea.

Russelll and Catalin:

Could you please give your advice on this?

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
author
#25 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

Quoted 53 lines · On 2012?02?01? 13:45, bill4carson wrote:
Quoted 23 lines · Russell King - ARM Linux
Quoted 12 lines · On Mon, Jan 30, 2012 at 03:57:15PM +0800, bill4carson at gmail.com wrote:

From: Bill Carson<[email protected]>

One easy way to store huge page linux pte is mm_struct instead of thread_info
that's because when parent task with huge page VMA calls fork, parent huge page
pagetable entries are copied into child pagetable. This is done in

int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)

Quoted 10 lines

We cannot derive child's thread_info just using struct mm_struct *dst. if we have struct mm_struct **dst, then it's easy to find the corresponding
task_struct as well as thread_info, but we only get struct mm_struct *dst.
It's possible to find the desired task_struct by iterating the global task list
by comparing task_struct->mm with dst.
So mm_struct is used for huge page linux pte for faster lookup and efficient.

Quoted 7 lines

I really do not understand this description, and it doesn't seem to tie up with the code. What problem are you trying to solve here?

Note that a mm_struct can be shared between multiple task_structs, so if your thinking is that something in the mm_struct or page table needs to know about a task_struct, you're ideas are wrong.

Normal page based pte has hardware version and linux version, these two kinds of
ptes occupy half of 4K page, and each of two pmd level entry pointer to this half 4K
page.

For huge page, mappings only exist in pmd level from hardware perspective, however
mm subsystem also needs to know the linux version *pte* of this huge page based
mapping, problems is where to store these huge page linux pte?

A:
Store huge page linux pte in mm_struct

B:
Store huge page linux pte in mm_context_t suggested by Catalin. This is almost like option A, while it's nice to modify arm code only and take small effort to make it happen.

Quoted 10 lines

C:
Modify pgd_alloc to allocate 2048 pgd_t entries plus two void pointers Use these two additional pointers to store huge page linux pte. It's feasible, but I don't know whether this is a good idea.

Russelll and Catalin:

Could you please give your advice on this?

Hi, Russell

I didn't mean to derive task_struct from a mm_struct, as you said, multiple tasks could possible share one mm_struct.

What I did is to store huge page linux pte on mm_struct(or mm_context_t), cause all hugetlb up layer hooks have mm_struct in parameters. IMHO, that's what I could figure out right now, if this idea sounds wrong or silly, please let me know.

And I'm wondering could you please review the other parts of this patch?

thanks

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#26 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

Quoted 17 lines · bill4carson wrote:

Normal page based pte has hardware version and linux version, these two kinds of ptes occupy half of 4K page, and each of two pmd level entry pointer to this half 4K page.

For huge page, mappings only exist in pmd level from hardware perspective, however mm subsystem also needs to know the linux version *pte* of this huge page based mapping, problems is where to store these huge page linux pte?

A:
Store huge page linux pte in mm_struct

B:
Store huge page linux pte in mm_context_t suggested by Catalin. This is almost like option A, while it's nice to modify arm code only and take small effort to make it happen.

Quoted 4 lines

C:
Modify pgd_alloc to allocate 2048 pgd_t entries plus two void pointers Use these two additional pointers to store huge page linux pte. It's feasible, but I don't know whether this is a good idea.

I wouldn't add this to pgd_alloc since not all tasks need huge pages. First option is also not feasible as we shouldn't touch generic code. This leaves us with B, unless better options are suggested.

I had a patch couple of years ago
(http://article.gmane.org/gmane.linux.ports.arm.kernel/55045) to use the AF (Access Flag) bit and free up some bits in the page table, allowing us to drop the Linux PTE. But we end up in a bigger configuration mess as we already have to choose between classic MMU and LPAE. The performance advantage wasn't that big either.

Signature · 1 line
Catalin
author
#27 lore raw

PATCH 4/7 Store huge page linux pte in mm_struct

2012/2/6, Catalin Marinas <[email protected]>:

Quoted 18 lines
Quoted 17 lines · bill4carson wrote:

Normal page based pte has hardware version and linux version, these two kinds of ptes occupy half of 4K page, and each of two pmd level entry pointer to this half 4K page.

For huge page, mappings only exist in pmd level from hardware perspective, however mm subsystem also needs to know the linux version *pte* of this huge page based mapping, problems is where to store these huge page linux pte?

A:
Store huge page linux pte in mm_struct

B:
Store huge page linux pte in mm_context_t suggested by Catalin. This is almost like option A, while it's nice to modify arm code only and take small effort to make it happen.

Quoted 9 lines
Quoted 4 lines

C:
Modify pgd_alloc to allocate 2048 pgd_t entries plus two void pointers Use these two additional pointers to store huge page linux pte. It's feasible, but I don't know whether this is a good idea.

I wouldn't add this to pgd_alloc since not all tasks need huge pages. First option is also not feasible as we shouldn't touch generic code. This leaves us with B, unless better options are suggested.

So far B sounds better, I will make that happens in V2. I don't know whether other guru have any opinion on this patch, Advice/suggestion/criticism are all truly welcome!

Quoted 9 lines

I had a patch couple of years ago
(http://article.gmane.org/gmane.linux.ports.arm.kernel/55045) to use the AF (Access Flag) bit and free up some bits in the page table, allowing us to drop the Linux PTE. But we end up in a bigger configuration mess as we already have to choose between classic MMU and LPAE. The performance advantage wasn't that big either.
--
Catalin

author
#28 lore raw

PATCH 5/7 Using do_page_fault for section fault handling

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/mm/fault.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
arch/arm/mm/fault.c +15 -0
index bb7eac3..af6703d 100644
@@ -19,6 +19,7 @@
 #include <linux/sched.h>
 #include <linux/highmem.h>
 #include <linux/perf_event.h>
+#include <linux/hugetlb.h>
 
 #include <asm/exception.h>
 #include <asm/system.h>

@@ -485,6 +486,7 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
 }
 #endif					/* CONFIG_MMU */
 
+#ifndef CONFIG_ARM_HUGETLB_SUPPORT
 /*
  * Some section permission faults need to be handled gracefully.
  * They can happen due to a __{get,put}_user during an oops.

@@ -496,6 +498,19 @@ do_sect_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	return 0;
 }
 
+#else
+
+/* Since normal 4K page based vma will never fault into section traps,
+ * This will enable us to use do_page_fault for section permission fault.
+ */
+static int
+do_sect_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
+{
+	do_page_fault(addr, fsr, regs);
+	return 0;
+}
+#endif
+
 /*
  * This abort handler always returns "fault".
  */
Signature · 1 line
1.7.1
author
#29 lore raw

PATCH 6/7 Add hugetlb Kconfig option

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/Kconfig |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)
arch/arm/Kconfig +29 -0
index a48aecc..161bca6 100644
@@ -985,6 +985,35 @@ config ARCH_ZYNQ
 	  Support for Xilinx Zynq ARM Cortex A9 Platform
 endchoice
 
+config SYS_SUPPORTS_HUGETLBFS
+		def_bool n
+
+config ARM_HUGETLB_SUPPORT
+	bool "Support HUGETLB for ARMv7 (EXPERIMENTAL)"
+	depends on CPU_V7 && EXPERIMENTAL
+	select SYS_SUPPORTS_HUGETLBFS
+	select HUGETLBFS
+	default y
+
+choice
+	prompt "Huge Page Size"
+	depends on ARM_HUGETLB_SUPPORT
+	default HUGEPAGE_SIZE_2MB
+
+config HUGEPAGE_SIZE_2MB
+	bool "2MB"
+	depends on ARM_HUGETLB_SUPPORT
+	help
+	 This option select huge page size in 2MB units
+
+config HUGEPAGE_SIZE_16MB
+	bool "16MB"
+	depends on ARM_HUGETLB_SUPPORT
+	help
+	  This option select huge page size in 16MB units
+
+endchoice
+
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
 # Kconfigs may be included either alphabetically (according to the
Signature · 1 line
1.7.1
author
#30 lore raw

PATCH 7/7 Minor compiling fix

In reply to bill4carson at gmail.com

From: Bill Carson <[email protected]>

Signed-off-by Bill Carson <[email protected]>
---
 arch/arm/mm/Makefile      |    1 +
 arch/arm/mm/dma-mapping.c |    3 ---
 2 files changed, 1 insertions(+), 3 deletions(-)
arch/arm/mm/Makefile +1 -0
index bca7e61..9348e1e 100644
@@ -99,4 +99,5 @@ AFLAGS_proc-v7.o	:=-Wa,-march=armv7-a
 obj-$(CONFIG_CACHE_FEROCEON_L2)	+= cache-feroceon-l2.o
 obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o
 obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
+obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlb.o
 obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
arch/arm/mm/dma-mapping.c +0 -3
index 1aa664a..8dc5fb4 100644
@@ -152,9 +152,6 @@ static struct arm_vmregion_head consistent_head = {
 	.vm_end		= CONSISTENT_END,
 };
 
-#ifdef CONFIG_HUGETLB_PAGE
-#error ARM Coherent DMA allocator does not (yet) support huge TLB
-#endif
 
 /*
  * Initialise the consistent memory allocation.
Signature · 1 line
1.7.1
#31 lore raw
In reply to bill4carson at gmail.com

Hi,

Quoted 3 lines · On 30 January 2012 07:57, <[email protected]> wrote:

This patch aims to support huge page for ARM. For now, 2MB(two 1MB page)/16MB huge page are supported, Versatile Express Cortex-A9x4 tile is used as test board. Verifications are running with libhugetlbfs and ltp.

I haven't reviewed your patches yet but just a few thoughts. Do you have a clear case where 16MB super-sections is needed? Do you have memory beyond 4G that can only be accessed with super-sections? This is an optional feature and not all processors have it. It also doesn't help much with the TLB hit rate since the micro-TLB most likely only support 1MB sections.

BTW, I have a (simpler) implementation of hugetlbfs with 2MB sections but for LPAE only:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=shortlog;h=refs/heads/hugetlb

Signature · 1 line
Catalin
author
#32 lore raw
Quoted 10 lines · Catalin Marinas

Hi,

Quoted 3 lines · On 30 January 2012 07:57,<[email protected]> wrote:

This patch aims to support huge page for ARM. For now, 2MB(two 1MB page)/16MB huge page are supported, Versatile Express Cortex-A9x4 tile is used as test board. Verifications are running with libhugetlbfs and ltp.

I haven't reviewed your patches yet but just a few thoughts. Do you have a clear case where 16MB super-sections is needed? Do you have memory beyond 4G that can only be accessed with super-sections? This is an optional feature and not all processors have it.

The initial support only focus on ARMv7 based processor like cortex A9, basically that's
what I got in my hand, one Versatile Express Cortex-A9x4 tile board.

Quoted 4 lines

It also doesn't
help much with the TLB hit rate since the micro-TLB most likely only support 1MB sections.

I am afraid I can't agree with you on this.
Truly there is no specific statement about whether micro-TLB support 16MB super-sections,
but main-TLB actually helps the hit rate, and main-TLB support all page size mapping.

Quoted 5 lines

BTW, I have a (simpler) implementation of hugetlbfs with 2MB sections but for LPAE only:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=shortlog;h=refs/heads/hugetlb

Thanks for your information, I will study your code carefully :)

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#33 lore raw
Quoted 10 lines · On 1 February 2012 01:56, bill4carson <[email protected]> wrote:
Quoted 3 lines · Catalin Marinas

It also doesn't
help much with the TLB hit rate since the micro-TLB most likely only support 1MB sections.

I am afraid I can't agree with you on this.
Truly there is no specific statement about whether micro-TLB support 16MB super-sections,
but main-TLB actually helps the hit rate, and main-TLB support all page size mapping.

The feedback over time was that 16MB didn't help much in terms of TLB misses compared to 1MB but that was for standard usage. I guess the hugetlbfs has specific scenarios that may benefit.

Anyway, could you make the 2MB/16MB huge page size configurable at boot time (command line option like on other architectures)? And also check the ID_MMFR0[31:28] for whether supersections are supported.

Quoted 7 lines
Quoted 6 lines

BTW, I have a (simpler) implementation of hugetlbfs with 2MB sections but for LPAE only:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=shortlog;h=refs/heads/hugetlb

Thanks for your information, I will study your code carefully :)

Most of the simplicity comes from the fact that LPAE doesn't need a separate Linux PTE table.

Signature · 1 line
Catalin
author
#34 lore raw
Quoted 10 lines · Catalin Marinas
Quoted 9 lines · On 1 February 2012 01:56, bill4carson<[email protected]> wrote:
Quoted 3 lines · Catalin Marinas

It also doesn't
help much with the TLB hit rate since the micro-TLB most likely only support 1MB sections.

I am afraid I can't agree with you on this.
Truly there is no specific statement about whether micro-TLB support 16MB super-sections,
but main-TLB actually helps the hit rate, and main-TLB support all page size mapping.

Quoted 6 lines

The feedback over time was that 16MB didn't help much in terms of TLB misses compared to 1MB but that was for standard usage. I guess the hugetlbfs has specific scenarios that may benefit.

Anyway, could you make the 2MB/16MB huge page size configurable at boot time (command line option like on other architectures)?

Actually, only X86 supports multiple page size configuration at boot time, other architectures
will has fixed huge page size once build.

I'm not sure it's a MUST to support multiple page size at boot time, but I'm sure this will make
marco "pte_pfn" much more complicated.

Quoted 3 lines

And also
check the ID_MMFR0[31:28] for whether supersections are supported.

Thanks for your tips :)

Quoted 10 lines
Quoted 7 lines
Quoted 6 lines

BTW, I have a (simpler) implementation of hugetlbfs with 2MB sections but for LPAE only:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=shortlog;h=refs/heads/hugetlb

Thanks for your information, I will study your code carefully :)

Most of the simplicity comes from the fact that LPAE doesn't need a separate Linux PTE table.

Signature · 4 lines
I am a slow learner
but I will keep trying to fight for my dreams!

--bill
#35 lore raw
Quoted 11 lines · On Fri, Feb 03, 2012 at 01:41:18AM +0000, bill4carson wrote:
Quoted 10 lines · Catalin Marinas
Quoted 9 lines · On 1 February 2012 01:56, bill4carson<[email protected]> wrote:
Quoted 3 lines · Catalin Marinas

It also doesn't
help much with the TLB hit rate since the micro-TLB most likely only support 1MB sections.

I am afraid I can't agree with you on this.
Truly there is no specific statement about whether micro-TLB support 16MB super-sections,
but main-TLB actually helps the hit rate, and main-TLB support all page size mapping.

Quoted 8 lines
Quoted 6 lines

The feedback over time was that 16MB didn't help much in terms of TLB misses compared to 1MB but that was for standard usage. I guess the hugetlbfs has specific scenarios that may benefit.

Anyway, could you make the 2MB/16MB huge page size configurable at boot time (command line option like on other architectures)?

Actually, only X86 supports multiple page size configuration at boot time, other architectures will has fixed huge page size once build.

Boot time would be just fine on ARM as well. But as we go towards single zImage, the super-sections may not be always available so one can always use sections as a fall-back.

Quoted 2 lines

I'm not sure it's a MUST to support multiple page size at boot time, but I'm sure this will make marco "pte_pfn" much more complicated.

I'm not entirely sure the complicated pte_pfn is needed (see my other comment).

Signature · 1 line
Catalin