[PATCH 0/3] Hugetlbfs support for riscv

[PATCH 0/3] Hugetlbfs support for riscv

[Alexandre Ghiti]

This series introduces hugetlbfs support for both riscv 32/64. Riscv32
is architecturally limited to huge pages of size 4MB whereas riscv64 has
2MB/1G huge pages support. Transparent huge page support is not
implemented here, I will submit another series later.

As stated in "The RISC-V Instruction Set Manual, Volume II: Privileged
Architecture", riscv page table entries are marked as non-leaf entries
as soon as at least one of the R/W/X bit set:

- pmd_huge/pud_huge check if one of those bits are set,
- pte_mkhuge simply returns the same pte value and does not set any of
  the R/W/X bits

CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
reserved gigantic pages can be freed: indeed, one can reduce the number
of huge pages by calling free_gigantic_pages which in turn calls
free_contig_range, defined only with those configs defined.
However I don't see any strong dependency between free_contig_range
and those configs, maybe we could allow hugetlbfs users to free boot
reserved hugepages without those configs activated, I will propose
something if Mike Kravetz agrees.

For the below validation, I activated CMA so that tests like counters do
not fail when freeing pages.
This series was validated using libhugetlbfs testsuite ported to riscv64
without linker script support.
(https://github.com/AlexGhiti/libhugetlbfs.git, branch dev/alex/riscv).

- libhugetlbfs testsuite on riscv64/2M:
  - brk_near_huge triggers an assert in malloc.c, does not on x86.

- libhugetlbfs testsuite on riscv64/1G:
  - brk_near_huge triggers an assert in malloc.c, does not on x86.
  - mmap-gettest, mmap-cow: testsuite passes the number of default free
    pages as parameters and then fails for 1G which is not the default.
    Otherwise succeeds when given the right number of pages.
  - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
    and fails at line 694 of fs/hugetlbfs/inode.c.
  - heapshrink on 1G fails on x86 too, not investigated.
  - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
    NULL in case of gigantic pages.
  - icache-hygiene succeeds after patch #3 of this series which lowers
    the base address of mmap.
  - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.

- libhugetlbfs testsuite on riscv32/4M: kernel build passes, lacks
  libhugetlbfs support for 32bits.

* Output for riscv64 2M and 1G libhugetbfs testsuite:

zero_filesize_segment (2M: 64):
zero_filesize_segment (1024M: 64):
test_root (2M: 64):     PASS
test_root (1024M: 64):  PASS
meminfo_nohuge (2M: 64):        PASS
meminfo_nohuge (1024M: 64):     PASS
gethugepagesize (2M: 64):       PASS
gethugepagesize (1024M: 64):    PASS
gethugepagesizes (2M: 64):      PASS
gethugepagesizes (1024M: 64):   PASS
HUGETLB_VERBOSE=1 empty_mounts (2M: 64):        PASS
HUGETLB_VERBOSE=1 empty_mounts (1024M: 64):     PASS
HUGETLB_VERBOSE=1 large_mounts (2M: 64):        PASS
HUGETLB_VERBOSE=1 large_mounts (1024M: 64):     PASS
find_path (2M: 64):     PASS
find_path (1024M: 64):  PASS
unlinked_fd (2M: 64):   PASS
unlinked_fd (1024M: 64):        PASS
readback (2M: 64):      PASS
readback (1024M: 64):   PASS
truncate (2M: 64):      PASS
truncate (1024M: 64):   PASS
shared (2M: 64):        PASS
shared (1024M: 64):     PASS
mprotect (2M: 64):      PASS
mprotect (1024M: 64):   PASS
mlock (2M: 64): PASS
mlock (1024M: 64):      PASS
misalign (2M: 64):      PASS
misalign (1024M: 64):   PASS
fallocate_basic.sh (2M: 64):    PASS
fallocate_basic.sh (1024M: 64): PASS
fallocate_align.sh (2M: 64):    PASS
fallocate_align.sh (1024M: 64): PASS
ptrace-write-hugepage (2M: 64): PASS
ptrace-write-hugepage (1024M: 64):      PASS
icache-hygiene (2M: 64):        PASS
icache-hygiene (1024M: 64):     PASS
slbpacaflush (2M: 64):  PASS (inconclusive)
slbpacaflush (1024M: 64):       PASS (inconclusive)
straddle_4GB_static (2M: 64):   PASS
straddle_4GB_static (1024M: 64):        PASS
huge_at_4GB_normal_below_static (2M: 64):       PASS
huge_at_4GB_normal_below_static (1024M: 64):    PASS
huge_below_4GB_normal_above_static (2M: 64):    PASS
huge_below_4GB_normal_above_static (1024M: 64): PASS
map_high_truncate_2 (2M: 64):   PASS
map_high_truncate_2 (1024M: 64):        FAIL    ftruncate(): Invalid
argument
misaligned_offset (2M: 64):     PASS (inconclusive)
misaligned_offset (1024M: 64):  PASS (inconclusive)
truncate_above_4GB (2M: 64):    PASS
truncate_above_4GB (1024M: 64): PASS
brk_near_huge (2M: 64): brk_near_huge: malloc.c:2385: sysmalloc:
Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
old_end & (pagesize - 1)) == 0)' failed.
brk_near_huge (1024M: 64):      brk_near_huge: malloc.c:2385: sysmalloc:
Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
old_end & (pagesize - 1)) == 0)' failed.
task-size-overrun (2M: 64):     PASS
task-size-overrun (1024M: 64):  PASS
stack_grow_into_huge (2M: 64):   PASS
stack_grow_into_huge (1024M: 64): PASS
corrupt-by-cow-opt (2M: 64):    PASS
corrupt-by-cow-opt (1024M: 64): PASS
noresv-preserve-resv-page (2M: 64):     PASS
noresv-preserve-resv-page (1024M: 64):  PASS
noresv-regarded-as-resv (2M: 64):       PASS
noresv-regarded-as-resv (1024M: 64):    PASS
readahead_reserve.sh (2M: 64):  PASS
readahead_reserve.sh (1024M: 64):       PASS
madvise_reserve.sh (2M: 64):    PASS
madvise_reserve.sh (1024M: 64): PASS
fadvise_reserve.sh (2M: 64):    PASS
fadvise_reserve.sh (1024M: 64): PASS
mremap-expand-slice-collision.sh (2M: 64):      PASS
mremap-expand-slice-collision.sh (1024M: 64):   PASS
mremap-fixed-normal-near-huge.sh (2M: 64):      PASS
mremap-fixed-normal-near-huge.sh (1024M: 64):   PASS
mremap-fixed-huge-near-normal.sh (2M: 64):      PASS
mremap-fixed-huge-near-normal.sh (1024M: 64):   PASS
set shmmax limit to 67108864
shm-perms (2M: 64):     PASS
private (2M: 64):       PASS
private (1024M: 64):    PASS
fork-cow (2M: 64):      PASS
fork-cow (1024M: 64):   PASS
direct (2M: 64):        Bad configuration: Failed to open direct-IO
file: Invalid argument
direct (1024M: 64):     Bad configuration: Failed to open direct-IO
file: File exists
malloc (2M: 64):        PASS
malloc (1024M: 64):     PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (2M: 64):
PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (1024M: 64):
PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
HUGETLB_MORECORE=yes malloc (2M: 64):      PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
HUGETLB_MORECORE=yes malloc (1024M: 64):PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
HUGETLB_MORECORE=yes malloc (2M: 64):    PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
HUGETLB_MORECORE=yes malloc (1024M: 64): PASS
malloc_manysmall (2M: 64):      PASS
malloc_manysmall (1024M: 64):   PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (2M:
64):      PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (1024M:
64):   PASS
heapshrink (2M: 64):    PASS
heapshrink (1024M: 64): PASS
LD_PRELOAD=libheapshrink.so heapshrink (2M: 64):        PASS
LD_PRELOAD=libheapshrink.so heapshrink (1024M: 64):     PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (2M: 64):
PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (1024M: 64):
PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
heapshrink (2M: 64):   PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
heapshrink (1024M: 64):        PASS
LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS (inconclusive)
LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
HUGETLB_MORECORE=yes heapshrink (1024M: 64):    PASS (inconclusive)
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
HUGETLB_MORECORE=yes heapshrink (1024M: 64):    FAIL    Heap did not
shrink
HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (2M: 64):  PASS
HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (1024M: 64):
PASS
HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
linkhuge (2M: 64):
linkhuge (1024M: 64):
LD_PRELOAD=libhugetlbfs.so linkhuge (2M: 64):
LD_PRELOAD=libhugetlbfs.so linkhuge (1024M: 64):
linkhuge_rw (2M: 64):
linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=no linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=no linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
chunk-overcommit (2M: 64):      PASS
chunk-overcommit (1024M: 64):   PASS
alloc-instantiate-race shared (2M: 64): PASS
alloc-instantiate-race shared (1024M: 64):      PASS
alloc-instantiate-race private (2M: 64):        PASS
alloc-instantiate-race private (1024M: 64):     PASS
truncate_reserve_wraparound (2M: 64):   PASS
truncate_reserve_wraparound (1024M: 64):        PASS
truncate_sigbus_versus_oom (2M: 64):    PASS
truncate_sigbus_versus_oom (1024M: 64): PASS
get_huge_pages (2M: 64):        PASS
get_huge_pages (1024M: 64):     PASS
shmoverride_linked (2M: 64):    PASS
HUGETLB_SHM=yes shmoverride_linked (2M: 64):    PASS
shmoverride_linked_static (2M: 64):
HUGETLB_SHM=yes shmoverride_linked_static (2M: 64):
LD_PRELOAD=libhugetlbfs.so shmoverride_unlinked (2M: 64):       PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M:
64):       PASS
quota.sh (2M: 64):      PASS
quota.sh (1024M: 64):   PASS
counters.sh (2M: 64):   PASS
counters.sh (1024M: 64):        FAIL mmap failed: Invalid argument
mmap-gettest 10 35 (2M: 64):    PASS
mmap-gettest 10 35 (1024M: 64): FAIL    Failed to mmap the hugetlb file:
Cannot allocate memory
mmap-cow 34 35 (2M: 64):        PASS
mmap-cow 34 35 (1024M: 64):     FAIL    Thread 15 (pid=514) failed
set shmmax limit to 73400320
shm-fork 10 17 (2M: 64):        PASS
set shmmax limit to 73400320
shm-fork 10 35 (2M: 64):        PASS
set shmmax limit to 73400320
shm-getraw 35 /dev/full (2M: 64):       PASS
fallocate_stress.sh (2M: 64):   libgcc_s.so.1 must be installed for
pthread_cancel to work
fallocate_stress.sh (1024M: 64):
********** TEST SUMMARY
*                      2M             1024M
*                      32-bit 64-bit  32-bit 64-bit
*     Total testcases:     0     93       0     83
*             Skipped:     0      0       0      0
*                PASS:     0     69       0     56
*                FAIL:     0      0       0      5
*    Killed by signal:     0      1       0      2
*   Bad configuration:     0      1       0      1
*       Expected FAIL:     0      0       0      0
*     Unexpected PASS:     0      0       0      0
*    Test not present:     0     21       0     19
* Strange test result:     0      1       0      0
**********

Alexandre Ghiti (3):
  riscv: Introduce huge page support for 32/64bit kernel
  riscv: Fix wrong comment about task size for riscv64
  riscv: Adjust mmap base address at a third of task size

 arch/riscv/Kconfig                 |  7 +++++++
 arch/riscv/include/asm/hugetlb.h   | 22 ++++++++++++++++++++++
 arch/riscv/include/asm/page.h      | 10 ++++++++++
 arch/riscv/include/asm/pgtable.h   |  8 ++++++--
 arch/riscv/include/asm/processor.h |  2 +-
 arch/riscv/mm/Makefile             |  2 ++
 arch/riscv/mm/hugetlbpage.c        | 36 ++++++++++++++++++++++++++++++++++++
 7 files changed, 84 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv/include/asm/hugetlb.h
 create mode 100644 arch/riscv/mm/hugetlbpage.c

-- 
2.16.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

[Alexandre Ghiti]

This patch implements both 4MB huge page support for 32bit kernel
and 2MB/1GB huge pages support for 64bit kernel.

Signed-off-by: Alexandre Ghiti <aghiti@upmem.com>
---
 arch/riscv/Kconfig               |  7 +++++++
 arch/riscv/include/asm/hugetlb.h | 22 ++++++++++++++++++++++
 arch/riscv/include/asm/page.h    | 10 ++++++++++
 arch/riscv/include/asm/pgtable.h |  6 +++++-
 arch/riscv/mm/Makefile           |  2 ++
 arch/riscv/mm/hugetlbpage.c      | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 arch/riscv/include/asm/hugetlb.h
 create mode 100644 arch/riscv/mm/hugetlbpage.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 55da93f4e818..7bb21533d927 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,12 @@ config PAGE_OFFSET
 	default 0xffffffff80000000 if 64BIT && MAXPHYSMEM_2GB
 	default 0xffffffe000000000 if 64BIT && MAXPHYSMEM_128GB
 
+config ARCH_WANT_GENERAL_HUGETLB
+	def_bool y
+
+config SYS_SUPPORTS_HUGETLBFS
+	def_bool y
+
 config STACKTRACE_SUPPORT
 	def_bool y
 
@@ -118,6 +124,7 @@ config ARCH_RV64I
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_DYNAMIC_FTRACE_WITH_REGS
 	select SWIOTLB
+	select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
 
 endchoice
 
diff --git a/arch/riscv/include/asm/hugetlb.h b/arch/riscv/include/asm/hugetlb.h
new file mode 100644
index 000000000000..b7d88cf4e315
--- /dev/null
+++ b/arch/riscv/include/asm/hugetlb.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_HUGETLB_H
+#define _ASM_RISCV_HUGETLB_H
+
+#include <asm-generic/hugetlb.h>
+#include <asm/page.h>
+
+static inline int is_hugepage_only_range(struct mm_struct *mm,
+					 unsigned long addr,
+					 unsigned long len) {
+	return 0;
+}
+
+static inline void arch_clear_hugepage_flags(struct page *page)
+{
+}
+
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
+
+#endif /* _ASM_RISCV_HUGETLB_H */
diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index 06cfbb3aacbb..ceaa73b82b25 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -24,6 +24,16 @@
 #define PAGE_SIZE	(_AC(1, UL) << PAGE_SHIFT)
 #define PAGE_MASK	(~(PAGE_SIZE - 1))
 
+#ifdef CONFIG_64BIT
+#define HUGE_MAX_HSTATE		2
+#else
+#define HUGE_MAX_HSTATE		1
+#endif
+#define HPAGE_SHIFT		PMD_SHIFT
+#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK              (~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER      (HPAGE_SHIFT - PAGE_SHIFT)
+
 /*
  * PAGE_OFFSET -- the first address of the first page of memory.
  * When not using MMU this corresponds to the first free page in
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 16301966d65b..50ea3d6e7de7 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -121,7 +121,6 @@ static inline void pmd_clear(pmd_t *pmdp)
 	set_pmd(pmdp, __pmd(0));
 }
 
-
 static inline pgd_t pfn_pgd(unsigned long pfn, pgprot_t prot)
 {
 	return __pgd((pfn << _PAGE_PFN_SHIFT) | pgprot_val(prot));
@@ -258,6 +257,11 @@ static inline pte_t pte_mkspecial(pte_t pte)
 	return __pte(pte_val(pte) | _PAGE_SPECIAL);
 }
 
+static inline pte_t pte_mkhuge(pte_t pte)
+{
+	return pte;
+}
+
 /* Modify page protection bits */
 static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 {
diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
index eb22ab49b3e0..eeadb130d7cf 100644
--- a/arch/riscv/mm/Makefile
+++ b/arch/riscv/mm/Makefile
@@ -3,3 +3,5 @@ obj-y += fault.o
 obj-y += extable.o
 obj-y += ioremap.o
 obj-y += cacheflush.o
+
+obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
new file mode 100644
index 000000000000..7bac8b22d486
--- /dev/null
+++ b/arch/riscv/mm/hugetlbpage.c
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <linux/hugetlb.h>
+#include <linux/err.h>
+
+int pud_huge(pud_t pud)
+{
+	return pud_present(pud)
+		&& (pud_val(pud) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
+}
+
+int pmd_huge(pmd_t pmd)
+{
+	return pmd_present(pmd)
+		&& (pmd_val(pmd) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
+}
+
+static __init int setup_hugepagesz(char *opt)
+{
+	unsigned long ps = memparse(opt, &opt);
+
+	if (ps == HPAGE_SIZE) {
+		hugetlb_add_hstate(HPAGE_SHIFT - PAGE_SHIFT);
+#if defined(CONFIG_64BIT)
+	} else if (ps == PUD_SIZE) {
+		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
+#endif
+	} else {
+		hugetlb_bad_size();
+		printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
+			ps >> 20);
+		return 0;
+	}
+
+	return 1;
+}
+__setup("hugepagesz=", setup_hugepagesz);
-- 
2.16.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/3] riscv: Fix wrong comment about task size for riscv64

[Alexandre Ghiti]

The comment indicated a wrong size which was misleading, after
the following computation, TASK_SIZE is in fact equal to
0x4000000000.

     TASK_SIZE  = (PGDIR_SIZE * PTRS_PER_PGD / 2)
with PGDIR_SIZE = 1 << 30 and PTRS_PER_PGD = 4K / 8 = 0x200
=>   TASK_SIZE = 0x40000000 * 0x100 = 0x4000000000

Signed-off-by: Alexandre Ghiti <aghiti@upmem.com>
---
 arch/riscv/include/asm/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 50ea3d6e7de7..db3bf0dccd0d 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -420,7 +420,7 @@ static inline void pgtable_cache_init(void)
 #define VMALLOC_START    (PAGE_OFFSET - VMALLOC_SIZE)
 
 /*
- * Task size is 0x40000000000 for RV64 or 0xb800000 for RV32.
+ * Task size is 0x4000000000 for RV64 or 0xb800000 for RV32.
  * Note that PGDIR_SIZE must evenly divide TASK_SIZE.
  */
 #ifdef CONFIG_64BIT
-- 
2.16.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Alexandre Ghiti]

This ratio is the most used among all other architectures and make
icache_hygiene libhugetlbfs test pass: this test mmap lots of
hugepages whose addresses, without this patch, reach the end of
the process user address space.

Signed-off-by: Alexandre Ghiti <aghiti@upmem.com>
---
 arch/riscv/include/asm/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index 0531f49af5c3..ce70bceb8872 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -22,7 +22,7 @@
  * This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */
-#define TASK_UNMAPPED_BASE	PAGE_ALIGN(TASK_SIZE >> 1)
+#define TASK_UNMAPPED_BASE	PAGE_ALIGN(TASK_SIZE / 3)
 
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		STACK_TOP
-- 
2.16.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alex Ghiti]

Hi everyone,

Can I do something more regarding this series ? Anything that would ease 
the review process, do not hesitate to ask.

Thanks,

Alex

On 12/10/18 6:21 AM, Alexandre Ghiti wrote:
> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
> is architecturally limited to huge pages of size 4MB whereas riscv64 has
> 2MB/1G huge pages support. Transparent huge page support is not
> implemented here, I will submit another series later.
>
> As stated in "The RISC-V Instruction Set Manual, Volume II: Privileged
> Architecture", riscv page table entries are marked as non-leaf entries
> as soon as at least one of the R/W/X bit set:
>
> - pmd_huge/pud_huge check if one of those bits are set,
> - pte_mkhuge simply returns the same pte value and does not set any of
>    the R/W/X bits
>
> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
> reserved gigantic pages can be freed: indeed, one can reduce the number
> of huge pages by calling free_gigantic_pages which in turn calls
> free_contig_range, defined only with those configs defined.
> However I don't see any strong dependency between free_contig_range
> and those configs, maybe we could allow hugetlbfs users to free boot
> reserved hugepages without those configs activated, I will propose
> something if Mike Kravetz agrees.
>
> For the below validation, I activated CMA so that tests like counters do
> not fail when freeing pages.
> This series was validated using libhugetlbfs testsuite ported to riscv64
> without linker script support.
> (https://github.com/AlexGhiti/libhugetlbfs.git, branch dev/alex/riscv).
>
> - libhugetlbfs testsuite on riscv64/2M:
>    - brk_near_huge triggers an assert in malloc.c, does not on x86.
>
> - libhugetlbfs testsuite on riscv64/1G:
>    - brk_near_huge triggers an assert in malloc.c, does not on x86.
>    - mmap-gettest, mmap-cow: testsuite passes the number of default free
>      pages as parameters and then fails for 1G which is not the default.
>      Otherwise succeeds when given the right number of pages.
>    - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>      and fails at line 694 of fs/hugetlbfs/inode.c.
>    - heapshrink on 1G fails on x86 too, not investigated.
>    - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>      NULL in case of gigantic pages.
>    - icache-hygiene succeeds after patch #3 of this series which lowers
>      the base address of mmap.
>    - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
>
> - libhugetlbfs testsuite on riscv32/4M: kernel build passes, lacks
>    libhugetlbfs support for 32bits.
>
> * Output for riscv64 2M and 1G libhugetbfs testsuite:
>
> zero_filesize_segment (2M: 64):
> zero_filesize_segment (1024M: 64):
> test_root (2M: 64):     PASS
> test_root (1024M: 64):  PASS
> meminfo_nohuge (2M: 64):        PASS
> meminfo_nohuge (1024M: 64):     PASS
> gethugepagesize (2M: 64):       PASS
> gethugepagesize (1024M: 64):    PASS
> gethugepagesizes (2M: 64):      PASS
> gethugepagesizes (1024M: 64):   PASS
> HUGETLB_VERBOSE=1 empty_mounts (2M: 64):        PASS
> HUGETLB_VERBOSE=1 empty_mounts (1024M: 64):     PASS
> HUGETLB_VERBOSE=1 large_mounts (2M: 64):        PASS
> HUGETLB_VERBOSE=1 large_mounts (1024M: 64):     PASS
> find_path (2M: 64):     PASS
> find_path (1024M: 64):  PASS
> unlinked_fd (2M: 64):   PASS
> unlinked_fd (1024M: 64):        PASS
> readback (2M: 64):      PASS
> readback (1024M: 64):   PASS
> truncate (2M: 64):      PASS
> truncate (1024M: 64):   PASS
> shared (2M: 64):        PASS
> shared (1024M: 64):     PASS
> mprotect (2M: 64):      PASS
> mprotect (1024M: 64):   PASS
> mlock (2M: 64): PASS
> mlock (1024M: 64):      PASS
> misalign (2M: 64):      PASS
> misalign (1024M: 64):   PASS
> fallocate_basic.sh (2M: 64):    PASS
> fallocate_basic.sh (1024M: 64): PASS
> fallocate_align.sh (2M: 64):    PASS
> fallocate_align.sh (1024M: 64): PASS
> ptrace-write-hugepage (2M: 64): PASS
> ptrace-write-hugepage (1024M: 64):      PASS
> icache-hygiene (2M: 64):        PASS
> icache-hygiene (1024M: 64):     PASS
> slbpacaflush (2M: 64):  PASS (inconclusive)
> slbpacaflush (1024M: 64):       PASS (inconclusive)
> straddle_4GB_static (2M: 64):   PASS
> straddle_4GB_static (1024M: 64):        PASS
> huge_at_4GB_normal_below_static (2M: 64):       PASS
> huge_at_4GB_normal_below_static (1024M: 64):    PASS
> huge_below_4GB_normal_above_static (2M: 64):    PASS
> huge_below_4GB_normal_above_static (1024M: 64): PASS
> map_high_truncate_2 (2M: 64):   PASS
> map_high_truncate_2 (1024M: 64):        FAIL    ftruncate(): Invalid
> argument
> misaligned_offset (2M: 64):     PASS (inconclusive)
> misaligned_offset (1024M: 64):  PASS (inconclusive)
> truncate_above_4GB (2M: 64):    PASS
> truncate_above_4GB (1024M: 64): PASS
> brk_near_huge (2M: 64): brk_near_huge: malloc.c:2385: sysmalloc:
> Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
> long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
> old_end & (pagesize - 1)) == 0)' failed.
> brk_near_huge (1024M: 64):      brk_near_huge: malloc.c:2385: sysmalloc:
> Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
> long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
> old_end & (pagesize - 1)) == 0)' failed.
> task-size-overrun (2M: 64):     PASS
> task-size-overrun (1024M: 64):  PASS
> stack_grow_into_huge (2M: 64):   PASS
> stack_grow_into_huge (1024M: 64): PASS
> corrupt-by-cow-opt (2M: 64):    PASS
> corrupt-by-cow-opt (1024M: 64): PASS
> noresv-preserve-resv-page (2M: 64):     PASS
> noresv-preserve-resv-page (1024M: 64):  PASS
> noresv-regarded-as-resv (2M: 64):       PASS
> noresv-regarded-as-resv (1024M: 64):    PASS
> readahead_reserve.sh (2M: 64):  PASS
> readahead_reserve.sh (1024M: 64):       PASS
> madvise_reserve.sh (2M: 64):    PASS
> madvise_reserve.sh (1024M: 64): PASS
> fadvise_reserve.sh (2M: 64):    PASS
> fadvise_reserve.sh (1024M: 64): PASS
> mremap-expand-slice-collision.sh (2M: 64):      PASS
> mremap-expand-slice-collision.sh (1024M: 64):   PASS
> mremap-fixed-normal-near-huge.sh (2M: 64):      PASS
> mremap-fixed-normal-near-huge.sh (1024M: 64):   PASS
> mremap-fixed-huge-near-normal.sh (2M: 64):      PASS
> mremap-fixed-huge-near-normal.sh (1024M: 64):   PASS
> set shmmax limit to 67108864
> shm-perms (2M: 64):     PASS
> private (2M: 64):       PASS
> private (1024M: 64):    PASS
> fork-cow (2M: 64):      PASS
> fork-cow (1024M: 64):   PASS
> direct (2M: 64):        Bad configuration: Failed to open direct-IO
> file: Invalid argument
> direct (1024M: 64):     Bad configuration: Failed to open direct-IO
> file: File exists
> malloc (2M: 64):        PASS
> malloc (1024M: 64):     PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (2M: 64):
> PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (1024M: 64):
> PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
> HUGETLB_MORECORE=yes malloc (2M: 64):      PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
> HUGETLB_MORECORE=yes malloc (1024M: 64):PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
> HUGETLB_MORECORE=yes malloc (2M: 64):    PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
> HUGETLB_MORECORE=yes malloc (1024M: 64): PASS
> malloc_manysmall (2M: 64):      PASS
> malloc_manysmall (1024M: 64):   PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (2M:
> 64):      PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (1024M:
> 64):   PASS
> heapshrink (2M: 64):    PASS
> heapshrink (1024M: 64): PASS
> LD_PRELOAD=libheapshrink.so heapshrink (2M: 64):        PASS
> LD_PRELOAD=libheapshrink.so heapshrink (1024M: 64):     PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (2M: 64):
> PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (1024M: 64):
> PASS
> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
> heapshrink (2M: 64):   PASS
> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
> heapshrink (1024M: 64):        PASS
> LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
> HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS (inconclusive)
> LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
> HUGETLB_MORECORE=yes heapshrink (1024M: 64):    PASS (inconclusive)
> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
> HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS
> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
> HUGETLB_MORECORE=yes heapshrink (1024M: 64):    FAIL    Heap did not
> shrink
> HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (2M: 64):  PASS
> HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (1024M: 64):
> PASS
> HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
> HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
> LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
> LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
> linkhuge (2M: 64):
> linkhuge (1024M: 64):
> LD_PRELOAD=libhugetlbfs.so linkhuge (2M: 64):
> LD_PRELOAD=libhugetlbfs.so linkhuge (1024M: 64):
> linkhuge_rw (2M: 64):
> linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=no linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=no linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
> HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
> HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
> HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
> HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
> chunk-overcommit (2M: 64):      PASS
> chunk-overcommit (1024M: 64):   PASS
> alloc-instantiate-race shared (2M: 64): PASS
> alloc-instantiate-race shared (1024M: 64):      PASS
> alloc-instantiate-race private (2M: 64):        PASS
> alloc-instantiate-race private (1024M: 64):     PASS
> truncate_reserve_wraparound (2M: 64):   PASS
> truncate_reserve_wraparound (1024M: 64):        PASS
> truncate_sigbus_versus_oom (2M: 64):    PASS
> truncate_sigbus_versus_oom (1024M: 64): PASS
> get_huge_pages (2M: 64):        PASS
> get_huge_pages (1024M: 64):     PASS
> shmoverride_linked (2M: 64):    PASS
> HUGETLB_SHM=yes shmoverride_linked (2M: 64):    PASS
> shmoverride_linked_static (2M: 64):
> HUGETLB_SHM=yes shmoverride_linked_static (2M: 64):
> LD_PRELOAD=libhugetlbfs.so shmoverride_unlinked (2M: 64):       PASS
> LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M:
> 64):       PASS
> quota.sh (2M: 64):      PASS
> quota.sh (1024M: 64):   PASS
> counters.sh (2M: 64):   PASS
> counters.sh (1024M: 64):        FAIL mmap failed: Invalid argument
> mmap-gettest 10 35 (2M: 64):    PASS
> mmap-gettest 10 35 (1024M: 64): FAIL    Failed to mmap the hugetlb file:
> Cannot allocate memory
> mmap-cow 34 35 (2M: 64):        PASS
> mmap-cow 34 35 (1024M: 64):     FAIL    Thread 15 (pid=514) failed
> set shmmax limit to 73400320
> shm-fork 10 17 (2M: 64):        PASS
> set shmmax limit to 73400320
> shm-fork 10 35 (2M: 64):        PASS
> set shmmax limit to 73400320
> shm-getraw 35 /dev/full (2M: 64):       PASS
> fallocate_stress.sh (2M: 64):   libgcc_s.so.1 must be installed for
> pthread_cancel to work
> fallocate_stress.sh (1024M: 64):
> ********** TEST SUMMARY
> *                      2M             1024M
> *                      32-bit 64-bit  32-bit 64-bit
> *     Total testcases:     0     93       0     83
> *             Skipped:     0      0       0      0
> *                PASS:     0     69       0     56
> *                FAIL:     0      0       0      5
> *    Killed by signal:     0      1       0      2
> *   Bad configuration:     0      1       0      1
> *       Expected FAIL:     0      0       0      0
> *     Unexpected PASS:     0      0       0      0
> *    Test not present:     0     21       0     19
> * Strange test result:     0      1       0      0
> **********
>
> Alexandre Ghiti (3):
>    riscv: Introduce huge page support for 32/64bit kernel
>    riscv: Fix wrong comment about task size for riscv64
>    riscv: Adjust mmap base address at a third of task size
>
>   arch/riscv/Kconfig                 |  7 +++++++
>   arch/riscv/include/asm/hugetlb.h   | 22 ++++++++++++++++++++++
>   arch/riscv/include/asm/page.h      | 10 ++++++++++
>   arch/riscv/include/asm/pgtable.h   |  8 ++++++--
>   arch/riscv/include/asm/processor.h |  2 +-
>   arch/riscv/mm/Makefile             |  2 ++
>   arch/riscv/mm/hugetlbpage.c        | 36 ++++++++++++++++++++++++++++++++++++
>   7 files changed, 84 insertions(+), 3 deletions(-)
>   create mode 100644 arch/riscv/include/asm/hugetlb.h
>   create mode 100644 arch/riscv/mm/hugetlbpage.c
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Paul Walmsley]

On Mon, 7 Jan 2019, Alex Ghiti wrote:

> Can I do something more regarding this series ? Anything that would ease the
> review process, do not hesitate to ask.

Does your series need to be rebased against v5.0-rc1 to apply cleanly?
If so, please rebase and repost. 


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alexandre Ghiti]

On 01/07/2019 10:52 PM, Paul Walmsley wrote:
> On Mon, 7 Jan 2019, Alex Ghiti wrote:
>
>> Can I do something more regarding this series ? Anything that would ease the
>> review process, do not hesitate to ask.
> Does your series need to be rebased against v5.0-rc1 to apply cleanly?
> If so, please rebase and repost.
>
>
> - Paul

The series applies nicely on top of v5.0-rc1 without modifications.

Thanks,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Palmer Dabbelt]

On Mon, 07 Jan 2019 09:57:16 PST (-0800), alex@ghiti.fr wrote:
> Hi everyone,
>
> Can I do something more regarding this series ? Anything that would ease
> the review process, do not hesitate to ask.

I don't actually see the original patch set in my inbox, which is why it didn't 
get looked at.  Can you give me a pointer so I can dig them up and look?

Sorry!

>
> Thanks,
>
> Alex
>
> On 12/10/18 6:21 AM, Alexandre Ghiti wrote:
>> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
>> is architecturally limited to huge pages of size 4MB whereas riscv64 has
>> 2MB/1G huge pages support. Transparent huge page support is not
>> implemented here, I will submit another series later.
>>
>> As stated in "The RISC-V Instruction Set Manual, Volume II: Privileged
>> Architecture", riscv page table entries are marked as non-leaf entries
>> as soon as at least one of the R/W/X bit set:
>>
>> - pmd_huge/pud_huge check if one of those bits are set,
>> - pte_mkhuge simply returns the same pte value and does not set any of
>>    the R/W/X bits
>>
>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>> reserved gigantic pages can be freed: indeed, one can reduce the number
>> of huge pages by calling free_gigantic_pages which in turn calls
>> free_contig_range, defined only with those configs defined.
>> However I don't see any strong dependency between free_contig_range
>> and those configs, maybe we could allow hugetlbfs users to free boot
>> reserved hugepages without those configs activated, I will propose
>> something if Mike Kravetz agrees.
>>
>> For the below validation, I activated CMA so that tests like counters do
>> not fail when freeing pages.
>> This series was validated using libhugetlbfs testsuite ported to riscv64
>> without linker script support.
>> (https://github.com/AlexGhiti/libhugetlbfs.git, branch dev/alex/riscv).
>>
>> - libhugetlbfs testsuite on riscv64/2M:
>>    - brk_near_huge triggers an assert in malloc.c, does not on x86.
>>
>> - libhugetlbfs testsuite on riscv64/1G:
>>    - brk_near_huge triggers an assert in malloc.c, does not on x86.
>>    - mmap-gettest, mmap-cow: testsuite passes the number of default free
>>      pages as parameters and then fails for 1G which is not the default.
>>      Otherwise succeeds when given the right number of pages.
>>    - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>>      and fails at line 694 of fs/hugetlbfs/inode.c.
>>    - heapshrink on 1G fails on x86 too, not investigated.
>>    - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>>      NULL in case of gigantic pages.
>>    - icache-hygiene succeeds after patch #3 of this series which lowers
>>      the base address of mmap.
>>    - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
>>
>> - libhugetlbfs testsuite on riscv32/4M: kernel build passes, lacks
>>    libhugetlbfs support for 32bits.
>>
>> * Output for riscv64 2M and 1G libhugetbfs testsuite:
>>
>> zero_filesize_segment (2M: 64):
>> zero_filesize_segment (1024M: 64):
>> test_root (2M: 64):     PASS
>> test_root (1024M: 64):  PASS
>> meminfo_nohuge (2M: 64):        PASS
>> meminfo_nohuge (1024M: 64):     PASS
>> gethugepagesize (2M: 64):       PASS
>> gethugepagesize (1024M: 64):    PASS
>> gethugepagesizes (2M: 64):      PASS
>> gethugepagesizes (1024M: 64):   PASS
>> HUGETLB_VERBOSE=1 empty_mounts (2M: 64):        PASS
>> HUGETLB_VERBOSE=1 empty_mounts (1024M: 64):     PASS
>> HUGETLB_VERBOSE=1 large_mounts (2M: 64):        PASS
>> HUGETLB_VERBOSE=1 large_mounts (1024M: 64):     PASS
>> find_path (2M: 64):     PASS
>> find_path (1024M: 64):  PASS
>> unlinked_fd (2M: 64):   PASS
>> unlinked_fd (1024M: 64):        PASS
>> readback (2M: 64):      PASS
>> readback (1024M: 64):   PASS
>> truncate (2M: 64):      PASS
>> truncate (1024M: 64):   PASS
>> shared (2M: 64):        PASS
>> shared (1024M: 64):     PASS
>> mprotect (2M: 64):      PASS
>> mprotect (1024M: 64):   PASS
>> mlock (2M: 64): PASS
>> mlock (1024M: 64):      PASS
>> misalign (2M: 64):      PASS
>> misalign (1024M: 64):   PASS
>> fallocate_basic.sh (2M: 64):    PASS
>> fallocate_basic.sh (1024M: 64): PASS
>> fallocate_align.sh (2M: 64):    PASS
>> fallocate_align.sh (1024M: 64): PASS
>> ptrace-write-hugepage (2M: 64): PASS
>> ptrace-write-hugepage (1024M: 64):      PASS
>> icache-hygiene (2M: 64):        PASS
>> icache-hygiene (1024M: 64):     PASS
>> slbpacaflush (2M: 64):  PASS (inconclusive)
>> slbpacaflush (1024M: 64):       PASS (inconclusive)
>> straddle_4GB_static (2M: 64):   PASS
>> straddle_4GB_static (1024M: 64):        PASS
>> huge_at_4GB_normal_below_static (2M: 64):       PASS
>> huge_at_4GB_normal_below_static (1024M: 64):    PASS
>> huge_below_4GB_normal_above_static (2M: 64):    PASS
>> huge_below_4GB_normal_above_static (1024M: 64): PASS
>> map_high_truncate_2 (2M: 64):   PASS
>> map_high_truncate_2 (1024M: 64):        FAIL    ftruncate(): Invalid
>> argument
>> misaligned_offset (2M: 64):     PASS (inconclusive)
>> misaligned_offset (1024M: 64):  PASS (inconclusive)
>> truncate_above_4GB (2M: 64):    PASS
>> truncate_above_4GB (1024M: 64): PASS
>> brk_near_huge (2M: 64): brk_near_huge: malloc.c:2385: sysmalloc:
>> Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
>> long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
>> old_end & (pagesize - 1)) == 0)' failed.
>> brk_near_huge (1024M: 64):      brk_near_huge: malloc.c:2385: sysmalloc:
>> Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned
>> long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
>> old_end & (pagesize - 1)) == 0)' failed.
>> task-size-overrun (2M: 64):     PASS
>> task-size-overrun (1024M: 64):  PASS
>> stack_grow_into_huge (2M: 64):   PASS
>> stack_grow_into_huge (1024M: 64): PASS
>> corrupt-by-cow-opt (2M: 64):    PASS
>> corrupt-by-cow-opt (1024M: 64): PASS
>> noresv-preserve-resv-page (2M: 64):     PASS
>> noresv-preserve-resv-page (1024M: 64):  PASS
>> noresv-regarded-as-resv (2M: 64):       PASS
>> noresv-regarded-as-resv (1024M: 64):    PASS
>> readahead_reserve.sh (2M: 64):  PASS
>> readahead_reserve.sh (1024M: 64):       PASS
>> madvise_reserve.sh (2M: 64):    PASS
>> madvise_reserve.sh (1024M: 64): PASS
>> fadvise_reserve.sh (2M: 64):    PASS
>> fadvise_reserve.sh (1024M: 64): PASS
>> mremap-expand-slice-collision.sh (2M: 64):      PASS
>> mremap-expand-slice-collision.sh (1024M: 64):   PASS
>> mremap-fixed-normal-near-huge.sh (2M: 64):      PASS
>> mremap-fixed-normal-near-huge.sh (1024M: 64):   PASS
>> mremap-fixed-huge-near-normal.sh (2M: 64):      PASS
>> mremap-fixed-huge-near-normal.sh (1024M: 64):   PASS
>> set shmmax limit to 67108864
>> shm-perms (2M: 64):     PASS
>> private (2M: 64):       PASS
>> private (1024M: 64):    PASS
>> fork-cow (2M: 64):      PASS
>> fork-cow (1024M: 64):   PASS
>> direct (2M: 64):        Bad configuration: Failed to open direct-IO
>> file: Invalid argument
>> direct (1024M: 64):     Bad configuration: Failed to open direct-IO
>> file: File exists
>> malloc (2M: 64):        PASS
>> malloc (1024M: 64):     PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (2M: 64):
>> PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (1024M: 64):
>> PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
>> HUGETLB_MORECORE=yes malloc (2M: 64):      PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:none
>> HUGETLB_MORECORE=yes malloc (1024M: 64):PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
>> HUGETLB_MORECORE=yes malloc (2M: 64):    PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
>> HUGETLB_MORECORE=yes malloc (1024M: 64): PASS
>> malloc_manysmall (2M: 64):      PASS
>> malloc_manysmall (1024M: 64):   PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (2M:
>> 64):      PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (1024M:
>> 64):   PASS
>> heapshrink (2M: 64):    PASS
>> heapshrink (1024M: 64): PASS
>> LD_PRELOAD=libheapshrink.so heapshrink (2M: 64):        PASS
>> LD_PRELOAD=libheapshrink.so heapshrink (1024M: 64):     PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (2M: 64):
>> PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (1024M: 64):
>> PASS
>> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
>> heapshrink (2M: 64):   PASS
>> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes
>> heapshrink (1024M: 64):        PASS
>> LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
>> HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS (inconclusive)
>> LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
>> HUGETLB_MORECORE=yes heapshrink (1024M: 64):    PASS (inconclusive)
>> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
>> HUGETLB_MORECORE=yes heapshrink (2M: 64):       PASS
>> LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE_SHRINK=yes
>> HUGETLB_MORECORE=yes heapshrink (1024M: 64):    FAIL    Heap did not
>> shrink
>> HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (2M: 64):  PASS
>> HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (1024M: 64):
>> PASS
>> HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
>> HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (2M: 64):
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (1024M: 64):
>> linkhuge (2M: 64):
>> linkhuge (1024M: 64):
>> LD_PRELOAD=libhugetlbfs.so linkhuge (2M: 64):
>> LD_PRELOAD=libhugetlbfs.so linkhuge (1024M: 64):
>> linkhuge_rw (2M: 64):
>> linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=no linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=no linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=R HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=W HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
>> HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 64):
>> HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=R linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=W linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=0 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (2M: 64):
>> HUGETLB_SHARE=1 HUGETLB_ELFMAP=RW linkhuge_rw (1024M: 64):
>> chunk-overcommit (2M: 64):      PASS
>> chunk-overcommit (1024M: 64):   PASS
>> alloc-instantiate-race shared (2M: 64): PASS
>> alloc-instantiate-race shared (1024M: 64):      PASS
>> alloc-instantiate-race private (2M: 64):        PASS
>> alloc-instantiate-race private (1024M: 64):     PASS
>> truncate_reserve_wraparound (2M: 64):   PASS
>> truncate_reserve_wraparound (1024M: 64):        PASS
>> truncate_sigbus_versus_oom (2M: 64):    PASS
>> truncate_sigbus_versus_oom (1024M: 64): PASS
>> get_huge_pages (2M: 64):        PASS
>> get_huge_pages (1024M: 64):     PASS
>> shmoverride_linked (2M: 64):    PASS
>> HUGETLB_SHM=yes shmoverride_linked (2M: 64):    PASS
>> shmoverride_linked_static (2M: 64):
>> HUGETLB_SHM=yes shmoverride_linked_static (2M: 64):
>> LD_PRELOAD=libhugetlbfs.so shmoverride_unlinked (2M: 64):       PASS
>> LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M:
>> 64):       PASS
>> quota.sh (2M: 64):      PASS
>> quota.sh (1024M: 64):   PASS
>> counters.sh (2M: 64):   PASS
>> counters.sh (1024M: 64):        FAIL mmap failed: Invalid argument
>> mmap-gettest 10 35 (2M: 64):    PASS
>> mmap-gettest 10 35 (1024M: 64): FAIL    Failed to mmap the hugetlb file:
>> Cannot allocate memory
>> mmap-cow 34 35 (2M: 64):        PASS
>> mmap-cow 34 35 (1024M: 64):     FAIL    Thread 15 (pid=514) failed
>> set shmmax limit to 73400320
>> shm-fork 10 17 (2M: 64):        PASS
>> set shmmax limit to 73400320
>> shm-fork 10 35 (2M: 64):        PASS
>> set shmmax limit to 73400320
>> shm-getraw 35 /dev/full (2M: 64):       PASS
>> fallocate_stress.sh (2M: 64):   libgcc_s.so.1 must be installed for
>> pthread_cancel to work
>> fallocate_stress.sh (1024M: 64):
>> ********** TEST SUMMARY
>> *                      2M             1024M
>> *                      32-bit 64-bit  32-bit 64-bit
>> *     Total testcases:     0     93       0     83
>> *             Skipped:     0      0       0      0
>> *                PASS:     0     69       0     56
>> *                FAIL:     0      0       0      5
>> *    Killed by signal:     0      1       0      2
>> *   Bad configuration:     0      1       0      1
>> *       Expected FAIL:     0      0       0      0
>> *     Unexpected PASS:     0      0       0      0
>> *    Test not present:     0     21       0     19
>> * Strange test result:     0      1       0      0
>> **********
>>
>> Alexandre Ghiti (3):
>>    riscv: Introduce huge page support for 32/64bit kernel
>>    riscv: Fix wrong comment about task size for riscv64
>>    riscv: Adjust mmap base address at a third of task size
>>
>>   arch/riscv/Kconfig                 |  7 +++++++
>>   arch/riscv/include/asm/hugetlb.h   | 22 ++++++++++++++++++++++
>>   arch/riscv/include/asm/page.h      | 10 ++++++++++
>>   arch/riscv/include/asm/pgtable.h   |  8 ++++++--
>>   arch/riscv/include/asm/processor.h |  2 +-
>>   arch/riscv/mm/Makefile             |  2 ++
>>   arch/riscv/mm/hugetlbpage.c        | 36 ++++++++++++++++++++++++++++++++++++
>>   7 files changed, 84 insertions(+), 3 deletions(-)
>>   create mode 100644 arch/riscv/include/asm/hugetlb.h
>>   create mode 100644 arch/riscv/mm/hugetlbpage.c
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Mike Kravetz]

On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
> is architecturally limited to huge pages of size 4MB whereas riscv64 has
> 2MB/1G huge pages support. Transparent huge page support is not
> implemented here, I will submit another series later.

Thanks for doing this.

Since patches only touch riscv specific code, I did not look too closely
and do not feel qualified to offer an opinion as to whether they are correct
for the architecture.

With that said, the patches do look reasonable with a few comments below.

> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
> reserved gigantic pages can be freed: indeed, one can reduce the number
> of huge pages by calling free_gigantic_pages which in turn calls
> free_contig_range, defined only with those configs defined.
> However I don't see any strong dependency between free_contig_range
> and those configs, maybe we could allow hugetlbfs users to free boot
> reserved hugepages without those configs activated, I will propose
> something if Mike Kravetz agrees.

Yes, that should be modified.  I think it would be a simple matter of moving
free_contig_range out of that ifdef block.  If you would like, I can submit
a patch for that.

Somewhat related, I do not think your patches enable dynamic allocation of
gigantic pages.  Not sure if that was an oversight or conscious decision.
I am not sure this is a highly used feature, but if you can do it on riscv
then why not?

Another 'missing feature' in your patches is PMD sharing.  This feature if
only of value for BIG shared hugetlbfs mappings.  DB folks like it.  As
mentioned above, I do not know much about riscv so I do not know if this
might be of use to potential users.

> - libhugetlbfs testsuite on riscv64/1G:
>   - brk_near_huge triggers an assert in malloc.c, does not on x86.
>   - mmap-gettest, mmap-cow: testsuite passes the number of default free
>     pages as parameters and then fails for 1G which is not the default.
>     Otherwise succeeds when given the right number of pages.
>   - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>     and fails at line 694 of fs/hugetlbfs/inode.c.
>   - heapshrink on 1G fails on x86 too, not investigated.
>   - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>     NULL in case of gigantic pages.
>   - icache-hygiene succeeds after patch #3 of this series which lowers
>     the base address of mmap.
>   - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.

In general, libhugetlbfs tests seem to have issues with anything besides
default huge page size.  You encountered that and noted that tests break
for 1G pages on x86 as well.  Cleaning all that up has been on my todo list
for years, but there always seems to be something of higher priority. :(

-- 
Mike Kravetz

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Palmer Dabbelt]

On Wed, 09 Jan 2019 11:23:22 PST (-0800), mike.kravetz@oracle.com wrote:
> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
>> is architecturally limited to huge pages of size 4MB whereas riscv64 has
>> 2MB/1G huge pages support. Transparent huge page support is not
>> implemented here, I will submit another series later.
>
> Thanks for doing this.
>
> Since patches only touch riscv specific code, I did not look too closely
> and do not feel qualified to offer an opinion as to whether they are correct
> for the architecture.o

Sorry about that.  These appear to have missed by inbox somehow.  I think they 
did manage to get caught by patchwork

    https://patchwork.kernel.org/cover/10720635/

I'll take a look...

> With that said, the patches do look reasonable with a few comments below.
>
>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>> reserved gigantic pages can be freed: indeed, one can reduce the number
>> of huge pages by calling free_gigantic_pages which in turn calls
>> free_contig_range, defined only with those configs defined.
>> However I don't see any strong dependency between free_contig_range
>> and those configs, maybe we could allow hugetlbfs users to free boot
>> reserved hugepages without those configs activated, I will propose
>> something if Mike Kravetz agrees.
>
> Yes, that should be modified.  I think it would be a simple matter of moving
> free_contig_range out of that ifdef block.  If you would like, I can submit
> a patch for that.
>
> Somewhat related, I do not think your patches enable dynamic allocation of
> gigantic pages.  Not sure if that was an oversight or conscious decision.
> I am not sure this is a highly used feature, but if you can do it on riscv
> then why not?
>
> Another 'missing feature' in your patches is PMD sharing.  This feature if
> only of value for BIG shared hugetlbfs mappings.  DB folks like it.  As
> mentioned above, I do not know much about riscv so I do not know if this
> might be of use to potential users.
>
>> - libhugetlbfs testsuite on riscv64/1G:
>>   - brk_near_huge triggers an assert in malloc.c, does not on x86.
>>   - mmap-gettest, mmap-cow: testsuite passes the number of default free
>>     pages as parameters and then fails for 1G which is not the default.
>>     Otherwise succeeds when given the right number of pages.
>>   - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>>     and fails at line 694 of fs/hugetlbfs/inode.c.
>>   - heapshrink on 1G fails on x86 too, not investigated.
>>   - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>>     NULL in case of gigantic pages.
>>   - icache-hygiene succeeds after patch #3 of this series which lowers
>>     the base address of mmap.
>>   - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
>
> In general, libhugetlbfs tests seem to have issues with anything besides
> default huge page size.  You encountered that and noted that tests break
> for 1G pages on x86 as well.  Cleaning all that up has been on my todo list
> for years, but there always seems to be something of higher priority. :(

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alex Ghiti]

On 1/9/19 10:15 PM, Palmer Dabbelt wrote:
> On Wed, 09 Jan 2019 11:23:22 PST (-0800), mike.kravetz@oracle.com wrote:
>> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>>> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
>>> is architecturally limited to huge pages of size 4MB whereas riscv64 
>>> has
>>> 2MB/1G huge pages support. Transparent huge page support is not
>>> implemented here, I will submit another series later.
>>
>> Thanks for doing this.
>>
>> Since patches only touch riscv specific code, I did not look too closely
>> and do not feel qualified to offer an opinion as to whether they are 
>> correct
>> for the architecture.o
>
> Sorry about that.  These appear to have missed by inbox somehow. I 
> think they did manage to get caught by patchwork
>
>    https://patchwork.kernel.org/cover/10720635/
>
> I'll take a look...
>

No problem Palmer :)

Thanks,


>> With that said, the patches do look reasonable with a few comments 
>> below.
>>
>>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>>> reserved gigantic pages can be freed: indeed, one can reduce the number
>>> of huge pages by calling free_gigantic_pages which in turn calls
>>> free_contig_range, defined only with those configs defined.
>>> However I don't see any strong dependency between free_contig_range
>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>> reserved hugepages without those configs activated, I will propose
>>> something if Mike Kravetz agrees.
>>
>> Yes, that should be modified.  I think it would be a simple matter of 
>> moving
>> free_contig_range out of that ifdef block.  If you would like, I can 
>> submit
>> a patch for that.
>>
>> Somewhat related, I do not think your patches enable dynamic 
>> allocation of
>> gigantic pages.  Not sure if that was an oversight or conscious 
>> decision.
>> I am not sure this is a highly used feature, but if you can do it on 
>> riscv
>> then why not?
>>
>> Another 'missing feature' in your patches is PMD sharing.  This 
>> feature if
>> only of value for BIG shared hugetlbfs mappings.  DB folks like it.  As
>> mentioned above, I do not know much about riscv so I do not know if this
>> might be of use to potential users.
>>
>>> - libhugetlbfs testsuite on riscv64/1G:
>>>   - brk_near_huge triggers an assert in malloc.c, does not on x86.
>>>   - mmap-gettest, mmap-cow: testsuite passes the number of default free
>>>     pages as parameters and then fails for 1G which is not the default.
>>>     Otherwise succeeds when given the right number of pages.
>>>   - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>>>     and fails at line 694 of fs/hugetlbfs/inode.c.
>>>   - heapshrink on 1G fails on x86 too, not investigated.
>>>   - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>>>     NULL in case of gigantic pages.
>>>   - icache-hygiene succeeds after patch #3 of this series which lowers
>>>     the base address of mmap.
>>>   - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
>>
>> In general, libhugetlbfs tests seem to have issues with anything besides
>> default huge page size.  You encountered that and noted that tests break
>> for 1G pages on x86 as well.  Cleaning all that up has been on my 
>> todo list
>> for years, but there always seems to be something of higher priority. :(
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alex Ghiti]

On 1/9/19 7:23 PM, Mike Kravetz wrote:
> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
>> is architecturally limited to huge pages of size 4MB whereas riscv64 has
>> 2MB/1G huge pages support. Transparent huge page support is not
>> implemented here, I will submit another series later.
> Thanks for doing this.
>
> Since patches only touch riscv specific code, I did not look too closely
> and do not feel qualified to offer an opinion as to whether they are correct
> for the architecture.
>
> With that said, the patches do look reasonable with a few comments below.
>
>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>> reserved gigantic pages can be freed: indeed, one can reduce the number
>> of huge pages by calling free_gigantic_pages which in turn calls
>> free_contig_range, defined only with those configs defined.
>> However I don't see any strong dependency between free_contig_range
>> and those configs, maybe we could allow hugetlbfs users to free boot
>> reserved hugepages without those configs activated, I will propose
>> something if Mike Kravetz agrees.
> Yes, that should be modified.  I think it would be a simple matter of moving
> free_contig_range out of that ifdef block.  If you would like, I can submit
> a patch for that.


I think there is more to do: free_gigantic_page is only defined with
ARCH_HAS_GIGANTIC_PAGE which in turn is only defined with
CMA || (MEMORY_ISOLATION && COMPACTION). Moreover, if
ARCH_HAS_GIGANTIC_PAGE is not defined, gigantic_page_supported
will return false and then function like update_and_free_page will
not reach the call to free_gigantic_page...etc. I will send you a patch
when I have fixed all of that :)


> Somewhat related, I do not think your patches enable dynamic allocation of
> gigantic pages.  Not sure if that was an oversight or conscious decision.
> I am not sure this is a highly used feature, but if you can do it on riscv
> then why not?

I'm not sure to understand: do you mean picking an already allocated
gigantic page or really allocating it with alloc_gigantic_page ? Or
something else ?


> Another 'missing feature' in your patches is PMD sharing.  This feature if
> only of value for BIG shared hugetlbfs mappings.  DB folks like it.  As
> mentioned above, I do not know much about riscv so I do not know if this
> might be of use to potential users.


Thanks for that, I was unaware of that feature, I will take a look.


>> - libhugetlbfs testsuite on riscv64/1G:
>>    - brk_near_huge triggers an assert in malloc.c, does not on x86.
>>    - mmap-gettest, mmap-cow: testsuite passes the number of default free
>>      pages as parameters and then fails for 1G which is not the default.
>>      Otherwise succeeds when given the right number of pages.
>>    - map_high_truncate_2 fails on x86 too: 0x60000000 is not 1G aligned
>>      and fails at line 694 of fs/hugetlbfs/inode.c.
>>    - heapshrink on 1G fails on x86 too, not investigated.
>>    - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>>      NULL in case of gigantic pages.
>>    - icache-hygiene succeeds after patch #3 of this series which lowers
>>      the base address of mmap.
>>    - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
> In general, libhugetlbfs tests seem to have issues with anything besides
> default huge page size.  You encountered that and noted that tests break
> for 1G pages on x86 as well.  Cleaning all that up has been on my todo list
> for years, but there always seems to be something of higher priority. :(
>
>

No problem, running the testsuite on x86 was quite simple anyway :)

Thanks Mike for your feedback,

Alex



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Mike Kravetz]

On 1/10/19 12:09 AM, Alex Ghiti wrote:
> On 1/9/19 7:23 PM, Mike Kravetz wrote:
>> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>>> However I don't see any strong dependency between free_contig_range
>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>> reserved hugepages without those configs activated, I will propose
>>> something if Mike Kravetz agrees.
>> Yes, that should be modified.  I think it would be a simple matter of moving
>> free_contig_range out of that ifdef block.  If you would like, I can submit
>> a patch for that.
> 
> 
> I think there is more to do: free_gigantic_page is only defined with
> ARCH_HAS_GIGANTIC_PAGE which in turn is only defined with
> CMA || (MEMORY_ISOLATION && COMPACTION). Moreover, if
> ARCH_HAS_GIGANTIC_PAGE is not defined, gigantic_page_supported
> will return false and then function like update_and_free_page will
> not reach the call to free_gigantic_page...etc. I will send you a patch
> when I have fixed all of that :)

Yes, I spoke too soon :)

>> Somewhat related, I do not think your patches enable dynamic allocation of
>> gigantic pages.  Not sure if that was an oversight or conscious decision.
>> I am not sure this is a highly used feature, but if you can do it on riscv
>> then why not?
> 
> I'm not sure to understand: do you mean picking an already allocated
> gigantic page or really allocating it with alloc_gigantic_page ? Or
> something else ?

The term 'dynamic allocation' may not be accurate.  Sorry!

Yes, I was talking about really allocating with alloc_gigantic_page.
It is possible to do this as long as the hstate for the gigantic page
size already exists.  If nothing is specified on the kernel boot command
line, the arch independent code will only set up the hstate for the default
huge page size.  x86 has this at the end of hugetlbpage.c to create the
gigantic page hstate as along as all config options are specified.

#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) ||
defined(CONFIG_CMA)
static __init int gigantic_pages_init(void)
{
	/* With compaction or CMA we can allocate gigantic pages at runtime */
	if (boot_cpu_has(X86_FEATURE_GBPAGES) && !size_to_hstate(1UL << PUD_SHIFT))
		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
	return 0;
}
arch_initcall(gigantic_pages_init);
#endif

I believe some other architectures do something similar to automatically
set up hstates other huge pages sizes at boot time.  Totally optional,
but you might want to do something like this for riscv.

-- 
Mike Kravetz

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

[Paul Walmsley]

Hello Alexandre,

On Mon, 10 Dec 2018, Alexandre Ghiti wrote:

> This patch implements both 4MB huge page support for 32bit kernel
> and 2MB/1GB huge pages support for 64bit kernel.
> 
> Signed-off-by: Alexandre Ghiti <aghiti@upmem.com>

This patch introduces a few minor checkpatch and strict checkpatch 
warnings, when tested against both v4.20 and v5.0-rc1 checkpatch versions.  
Could you fix those?  The other two patches in the series look OK from 
that point of view.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

[Alexandre Ghiti]

On 01/11/2019 07:18 AM, Paul Walmsley wrote:
> Hello Alexandre,
>
> On Mon, 10 Dec 2018, Alexandre Ghiti wrote:
>
>> This patch implements both 4MB huge page support for 32bit kernel
>> and 2MB/1GB huge pages support for 64bit kernel.
>>
>> Signed-off-by: Alexandre Ghiti <aghiti@upmem.com>
> This patch introduces a few minor checkpatch and strict checkpatch
> warnings, when tested against both v4.20 and v5.0-rc1 checkpatch versions.
> Could you fix those?  The other two patches in the series look OK from
> that point of view.

Yes, I had noted those warnings:

- the SPDX warning is weird, in all *.c files, the script seems to 
accept only
   "// SPDX-License-Identifier: GPL-2.0" and not "/* 
SPDX-License-Identifier: GPL-2.0 */".
   But on *.h files, this the contrary, maybe I missed something, I am going
   to take a look at the script spdxcheck.py.
   Note that kernel/ftrace.c and kernel/perf_event.c raise the same 
strange warning.

- I'll change the "printk(KERN_ERR" into a pr_err.

- I'll ignore the last warning regarding the new file.

Thanks for your feedback Paul,

Alex

>
>
> - Paul
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alex Ghiti]

On 1/10/19 6:28 PM, Mike Kravetz wrote:
> On 1/10/19 12:09 AM, Alex Ghiti wrote:
>> On 1/9/19 7:23 PM, Mike Kravetz wrote:
>>> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>>>> However I don't see any strong dependency between free_contig_range
>>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>>> reserved hugepages without those configs activated, I will propose
>>>> something if Mike Kravetz agrees.
>>> Yes, that should be modified.  I think it would be a simple matter of moving
>>> free_contig_range out of that ifdef block.  If you would like, I can submit
>>> a patch for that.
>>
>> I think there is more to do: free_gigantic_page is only defined with
>> ARCH_HAS_GIGANTIC_PAGE which in turn is only defined with
>> CMA || (MEMORY_ISOLATION && COMPACTION). Moreover, if
>> ARCH_HAS_GIGANTIC_PAGE is not defined, gigantic_page_supported
>> will return false and then function like update_and_free_page will
>> not reach the call to free_gigantic_page...etc. I will send you a patch
>> when I have fixed all of that :)
> Yes, I spoke too soon :)
>
>>> Somewhat related, I do not think your patches enable dynamic allocation of
>>> gigantic pages.  Not sure if that was an oversight or conscious decision.
>>> I am not sure this is a highly used feature, but if you can do it on riscv
>>> then why not?
>> I'm not sure to understand: do you mean picking an already allocated
>> gigantic page or really allocating it with alloc_gigantic_page ? Or
>> something else ?
> The term 'dynamic allocation' may not be accurate.  Sorry!
>
> Yes, I was talking about really allocating with alloc_gigantic_page.
> It is possible to do this as long as the hstate for the gigantic page
> size already exists.  If nothing is specified on the kernel boot command
> line, the arch independent code will only set up the hstate for the default
> huge page size.  x86 has this at the end of hugetlbpage.c to create the
> gigantic page hstate as along as all config options are specified.
>
> #if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) ||
> defined(CONFIG_CMA)
> static __init int gigantic_pages_init(void)
> {
> 	/* With compaction or CMA we can allocate gigantic pages at runtime */
> 	if (boot_cpu_has(X86_FEATURE_GBPAGES) && !size_to_hstate(1UL << PUD_SHIFT))
> 		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
> 	return 0;
> }
> arch_initcall(gigantic_pages_init);
> #endif
>
> I believe some other architectures do something similar to automatically
> set up hstates other huge pages sizes at boot time.  Totally optional,
> but you might want to do something like this for riscv.


Ok, I understand now, I agree that we should allow non default huge
page allocation even if not explicitly specified on kernel command line
paramter. I'll add an __init function to init hstate for gigantic page.

Thanks Mike,

Alex



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/3] riscv: Fix wrong comment about task size for riscv64

[Christoph Hellwig]

Looks fine to me, and should go in independent of the hugetlb support.

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Christoph Hellwig]

On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
> This ratio is the most used among all other architectures and make
> icache_hygiene libhugetlbfs test pass: this test mmap lots of
> hugepages whose addresses, without this patch, reach the end of
> the process user address space.

This does indeed look common, so this looks sensible to me and might
be worth picking up ASAP even without the hugetlb support:

Reviewed-by: Christoph Hellwig <hch@lst.de>

I wonder if we should provide this value as a defualt
TASK_UNMAPPED_BASE if the architecture doesn't provide one.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Christoph Hellwig]

On Wed, Jan 09, 2019 at 11:23:22AM -0800, Mike Kravetz wrote:
> > CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
> > reserved gigantic pages can be freed: indeed, one can reduce the number
> > of huge pages by calling free_gigantic_pages which in turn calls
> > free_contig_range, defined only with those configs defined.
> > However I don't see any strong dependency between free_contig_range
> > and those configs, maybe we could allow hugetlbfs users to free boot
> > reserved hugepages without those configs activated, I will propose
> > something if Mike Kravetz agrees.
> 
> Yes, that should be modified.  I think it would be a simple matter of moving
> free_contig_range out of that ifdef block.  If you would like, I can submit
> a patch for that.

We should probably include that patch in this series.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

[Christoph Hellwig]

> +#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
> +static inline bool gigantic_page_supported(void) { return true; }

Can you move each brace and the return statement to an line of its
own?  Just to keep the code a little easier to read.

> +int pud_huge(pud_t pud)
> +{
> +	return pud_present(pud)
> +		&& (pud_val(pud) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
> +}
> +
> +int pmd_huge(pmd_t pmd)
> +{
> +	return pmd_present(pmd)
> +		&& (pmd_val(pmd) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
> +}

Kinda sad that we can't easily have these as inline functions, but not
really your fault.  Note that the && should move to the first line
of the multi-line statement.

> +#if defined(CONFIG_64BIT)
> +	} else if (ps == PUD_SIZE) {
> +		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
> +#endif

I think this could be:

	} else if (IS_ENABLED(CONFIG_64BIT) && ps == PUD_SIZE) {
		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

[Alex Ghiti]

On 1/15/19 4:11 PM, Christoph Hellwig wrote:
>> +#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
>> +static inline bool gigantic_page_supported(void) { return true; }
> Can you move each brace and the return statement to an line of its
> own?  Just to keep the code a little easier to read.
>
>> +int pud_huge(pud_t pud)
>> +{
>> +	return pud_present(pud)
>> +		&& (pud_val(pud) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
>> +}
>> +
>> +int pmd_huge(pmd_t pmd)
>> +{
>> +	return pmd_present(pmd)
>> +		&& (pmd_val(pmd) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC));
>> +}
> Kinda sad that we can't easily have these as inline functions, but not
> really your fault.  Note that the && should move to the first line
> of the multi-line statement.
>
>> +#if defined(CONFIG_64BIT)
>> +	} else if (ps == PUD_SIZE) {
>> +		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>> +#endif
> I think this could be:
>
> 	} else if (IS_ENABLED(CONFIG_64BIT) && ps == PUD_SIZE) {
> 		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>
Thanks Christoph, I will send a new version with your modifications.


>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/3] riscv: Fix wrong comment about task size for riscv64

[Alex Ghiti]

On 1/15/19 3:58 PM, Christoph Hellwig wrote:
> Looks fine to me, and should go in independent of the hugetlb support.
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks for your review,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Alex Ghiti]

On 1/15/19 4:02 PM, Christoph Hellwig wrote:
> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>> This ratio is the most used among all other architectures and make
>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>> hugepages whose addresses, without this patch, reach the end of
>> the process user address space.
> This does indeed look common, so this looks sensible to me and might
> be worth picking up ASAP even without the hugetlb support:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> I wonder if we should provide this value as a defualt
> TASK_UNMAPPED_BASE if the architecture doesn't provide one.

Thanks for your review.
I think you're right regarding having a default version of 
TASK_UNMAPPED_BASE,
I will propose something.

Alex


> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alex Ghiti]

On 1/15/19 4:04 PM, Christoph Hellwig wrote:
> On Wed, Jan 09, 2019 at 11:23:22AM -0800, Mike Kravetz wrote:
>>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>>> reserved gigantic pages can be freed: indeed, one can reduce the number
>>> of huge pages by calling free_gigantic_pages which in turn calls
>>> free_contig_range, defined only with those configs defined.
>>> However I don't see any strong dependency between free_contig_range
>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>> reserved hugepages without those configs activated, I will propose
>>> something if Mike Kravetz agrees.
>> Yes, that should be modified.  I think it would be a simple matter of moving
>> free_contig_range out of that ifdef block.  If you would like, I can submit
>> a patch for that.
> We should probably include that patch in this series.

Ok, the patch for this is ready, I will include it in the series with your
comments.

Thanks again for your reviews,

Alex

>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Mike Kravetz]

On 1/15/19 8:04 AM, Christoph Hellwig wrote:
> On Wed, Jan 09, 2019 at 11:23:22AM -0800, Mike Kravetz wrote:
>>> CMA or (MEMORY_ISOLATION && COMPACTION) must be enabled so that boot
>>> reserved gigantic pages can be freed: indeed, one can reduce the number
>>> of huge pages by calling free_gigantic_pages which in turn calls
>>> free_contig_range, defined only with those configs defined.
>>> However I don't see any strong dependency between free_contig_range
>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>> reserved hugepages without those configs activated, I will propose
>>> something if Mike Kravetz agrees.
>>
>> Yes, that should be modified.  I think it would be a simple matter of moving
>> free_contig_range out of that ifdef block.  If you would like, I can submit
>> a patch for that.
> 
> We should probably include that patch in this series.

I would actually prefer that this be a separate patch.  Why?
- The functionality is arch independent and not specific to riscv.
- This functionality was intended in commit 944d9fec8d7a ("hugetlb:
  add support for gigantic page allocation at runtime").  However,
  there was no need to tie the functionality to CMA or (MEMORY_ISOLATION
  && COMPACTION).

I don't care enough to insist the patch be separate.  Just seems like
it should be separate to me.
-- 
Mike Kravetz

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Christoph Hellwig]

On Tue, Jan 15, 2019 at 11:25:07AM -0800, Mike Kravetz wrote:
> I would actually prefer that this be a separate patch.  Why?
> - The functionality is arch independent and not specific to riscv.
> - This functionality was intended in commit 944d9fec8d7a ("hugetlb:
>   add support for gigantic page allocation at runtime").  However,
>   there was no need to tie the functionality to CMA or (MEMORY_ISOLATION
>   && COMPACTION).
> 
> I don't care enough to insist the patch be separate.  Just seems like
> it should be separate to me.

Oh, I agree it should be a separate patch.  But it would be nice to
merge it together with the RISC-V hugetlb support, so that it can
depend on the patch instead of the current somewhat odd Kconfig
dependencies.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/3] Hugetlbfs support for riscv

[Alexandre Ghiti]

On 01/15/2019 09:52 PM, Christoph Hellwig wrote:
> On Tue, Jan 15, 2019 at 11:25:07AM -0800, Mike Kravetz wrote:
>> I would actually prefer that this be a separate patch.  Why?
>> - The functionality is arch independent and not specific to riscv.
>> - This functionality was intended in commit 944d9fec8d7a ("hugetlb:
>>    add support for gigantic page allocation at runtime").  However,
>>    there was no need to tie the functionality to CMA or (MEMORY_ISOLATION
>>    && COMPACTION).
>>
>> I don't care enough to insist the patch be separate.  Just seems like
>> it should be separate to me.
> Oh, I agree it should be a separate patch.  But it would be nice to
> merge it together with the RISC-V hugetlb support, so that it can
> depend on the patch instead of the current somewhat odd Kconfig
> dependencies.

Ok, I will submit the patch regarding the possibility to free gigantic
pages whatever the configuration is separately and rebase the riscv
hugetlbfs support on top of it.

Thanks for your feedbacks,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Palmer Dabbelt]

On Tue, 15 Jan 2019 08:02:06 PST (-0800), Christoph Hellwig wrote:
> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>> This ratio is the most used among all other architectures and make
>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>> hugepages whose addresses, without this patch, reach the end of
>> the process user address space.
>
> This does indeed look common, so this looks sensible to me and might
> be worth picking up ASAP even without the hugetlb support:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Makes sense to me.  I'll take it in to the next PR.

> I wonder if we should provide this value as a defualt
> TASK_UNMAPPED_BASE if the architecture doesn't provide one.

Looks like arm64 divides by 4 instead of 3.  It appears to have been that way 
since the start:

    commit 4f04d8f00545110a0e525ae2fb62ab38cb417236
    Author: Catalin Marinas <catalin.marinas@arm.com>
    Date:   Mon Mar 5 11:49:27 2012 +0000
    
        arm64: MMU definitions
        ...

so maybe that's the right answer?

On Tue, 15 Jan 2019 10:54:27 PST (-0800), alex@ghiti.fr wrote:
> On 1/15/19 4:02 PM, Christoph Hellwig wrote:
>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>> This ratio is the most used among all other architectures and make
>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>> hugepages whose addresses, without this patch, reach the end of
>>> the process user address space.
>> This does indeed look common, so this looks sensible to me and might
>> be worth picking up ASAP even without the hugetlb support:
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>> I wonder if we should provide this value as a defualt
>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>
> Thanks for your review.
> I think you're right regarding having a default version of
> TASK_UNMAPPED_BASE,
> I will propose something.

Sounds good to me.  I don't see anything, so I'm still going to take the patch 
-- we can always drop the redundant definition later.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Alex Ghiti]

On 1/25/19 2:02 PM, Palmer Dabbelt wrote:
> On Tue, 15 Jan 2019 08:02:06 PST (-0800), Christoph Hellwig wrote:
>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>> This ratio is the most used among all other architectures and make
>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>> hugepages whose addresses, without this patch, reach the end of
>>> the process user address space.
>>
>> This does indeed look common, so this looks sensible to me and might
>> be worth picking up ASAP even without the hugetlb support:
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> Makes sense to me.  I'll take it in to the next PR.
>
>> I wonder if we should provide this value as a defualt
>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>
> Looks like arm64 divides by 4 instead of 3.  It appears to have been 
> that way since the start:
>
>    commit 4f04d8f00545110a0e525ae2fb62ab38cb417236
>    Author: Catalin Marinas <catalin.marinas@arm.com>
>    Date:   Mon Mar 5 11:49:27 2012 +0000
>           arm64: MMU definitions
>        ...
>
> so maybe that's the right answer?

Maybe, I can't find explanations regarding this arbitrary value.

>
> On Tue, 15 Jan 2019 10:54:27 PST (-0800), alex@ghiti.fr wrote:
>> On 1/15/19 4:02 PM, Christoph Hellwig wrote:
>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>> This ratio is the most used among all other architectures and make
>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>> hugepages whose addresses, without this patch, reach the end of
>>>> the process user address space.
>>> This does indeed look common, so this looks sensible to me and might
>>> be worth picking up ASAP even without the hugetlb support:
>>>
>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>
>>> I wonder if we should provide this value as a defualt
>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>
>> Thanks for your review.
>> I think you're right regarding having a default version of
>> TASK_UNMAPPED_BASE,
>> I will propose something.
>
> Sounds good to me.  I don't see anything, so I'm still going to take 
> the patch -- we can always drop the redundant definition later.

I did not propose anything yet, I will take the time to find something 
more consistent.

Thanks Palmer,


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Alex Ghiti]

On 1/26/19 4:23 AM, Alex Ghiti wrote:
> On 1/25/19 2:02 PM, Palmer Dabbelt wrote:
>> On Tue, 15 Jan 2019 08:02:06 PST (-0800), Christoph Hellwig wrote:
>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>> This ratio is the most used among all other architectures and make
>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>> hugepages whose addresses, without this patch, reach the end of
>>>> the process user address space.
>>>
>>> This does indeed look common, so this looks sensible to me and might
>>> be worth picking up ASAP even without the hugetlb support:
>>>
>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>> Makes sense to me.  I'll take it in to the next PR.
>>
>>> I wonder if we should provide this value as a defualt
>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>
>> Looks like arm64 divides by 4 instead of 3.  It appears to have been 
>> that way since the start:
>>
>>    commit 4f04d8f00545110a0e525ae2fb62ab38cb417236
>>    Author: Catalin Marinas <catalin.marinas@arm.com>
>>    Date:   Mon Mar 5 11:49:27 2012 +0000
>>           arm64: MMU definitions
>>        ...
>>
>> so maybe that's the right answer?
>
> Maybe, I can't find explanations regarding this arbitrary value.
>
>>
>> On Tue, 15 Jan 2019 10:54:27 PST (-0800), alex@ghiti.fr wrote:
>>> On 1/15/19 4:02 PM, Christoph Hellwig wrote:
>>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>>> This ratio is the most used among all other architectures and make
>>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>>> hugepages whose addresses, without this patch, reach the end of
>>>>> the process user address space.
>>>> This does indeed look common, so this looks sensible to me and might
>>>> be worth picking up ASAP even without the hugetlb support:
>>>>
>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>>
>>>> I wonder if we should provide this value as a defualt
>>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>>
>>> Thanks for your review.
>>> I think you're right regarding having a default version of
>>> TASK_UNMAPPED_BASE,
>>> I will propose something.
>>
>> Sounds good to me.  I don't see anything, so I'm still going to take 
>> the patch -- we can always drop the redundant definition later.
>
> I did not propose anything yet, I will take the time to find something 
> more consistent.
>
> Thanks Palmer,
>
>

Hi Palmer,

I have just sent another patch regarding this issue, I think both are 
needed, I don't know
how you want me to proceed, should I merge them, should I rebase this 
one on top of the new
one (or the contrary)...

Thanks,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

[Alexandre Ghiti]

On 01/27/2019 05:57 PM, Alex Ghiti wrote:
> On 1/26/19 4:23 AM, Alex Ghiti wrote:
>> On 1/25/19 2:02 PM, Palmer Dabbelt wrote:
>>> On Tue, 15 Jan 2019 08:02:06 PST (-0800), Christoph Hellwig wrote:
>>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>>> This ratio is the most used among all other architectures and make
>>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>>> hugepages whose addresses, without this patch, reach the end of
>>>>> the process user address space.
>>>>
>>>> This does indeed look common, so this looks sensible to me and might
>>>> be worth picking up ASAP even without the hugetlb support:
>>>>
>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>
>>> Makes sense to me.  I'll take it in to the next PR.
>>>
>>>> I wonder if we should provide this value as a defualt
>>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>>
>>> Looks like arm64 divides by 4 instead of 3.  It appears to have been 
>>> that way since the start:
>>>
>>>    commit 4f04d8f00545110a0e525ae2fb62ab38cb417236
>>>    Author: Catalin Marinas <catalin.marinas@arm.com>
>>>    Date:   Mon Mar 5 11:49:27 2012 +0000
>>>           arm64: MMU definitions
>>>        ...
>>>
>>> so maybe that's the right answer?
>>
>> Maybe, I can't find explanations regarding this arbitrary value.
>>
>>>
>>> On Tue, 15 Jan 2019 10:54:27 PST (-0800), alex@ghiti.fr wrote:
>>>> On 1/15/19 4:02 PM, Christoph Hellwig wrote:
>>>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>>>> This ratio is the most used among all other architectures and make
>>>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>>>> hugepages whose addresses, without this patch, reach the end of
>>>>>> the process user address space.
>>>>> This does indeed look common, so this looks sensible to me and might
>>>>> be worth picking up ASAP even without the hugetlb support:
>>>>>
>>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>>>
>>>>> I wonder if we should provide this value as a defualt
>>>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>>>
>>>> Thanks for your review.
>>>> I think you're right regarding having a default version of
>>>> TASK_UNMAPPED_BASE,
>>>> I will propose something.
>>>
>>> Sounds good to me.  I don't see anything, so I'm still going to take 
>>> the patch -- we can always drop the redundant definition later.
>>
>> I did not propose anything yet, I will take the time to find 
>> something more consistent.
>>
>> Thanks Palmer,
>>
>>
>
> Hi Palmer,
>
> I have just sent another patch regarding this issue, I think both are 
> needed, I don't know
> how you want me to proceed, should I merge them, should I rebase this 
> one on top of the new
> one (or the contrary)...
>
> Thanks,
>
> Alex 

I should have thought more: I will send another version
of my top-down patch rebased against this one, because this patch
is required.

Indeed, there are 2 mmap allocation modes:

- bottom-up which starts allocation using TASK_UNMAPPED_BASE as
   base address,
- top-down which can be used only if the stack size has a limit and
   current personality does not have ADDR_COMPAT_LAYOUT set.

So, in any case, we need to provide the bottom up allocation scheme
and then this patch is required.

Sorry for the noise,

Alex

>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/3] riscv: Fix wrong comment about task size for riscv64

[Alexandre Ghiti]

On 01/15/2019 07:53 PM, Alex Ghiti wrote:
> On 1/15/19 3:58 PM, Christoph Hellwig wrote:
>> Looks fine to me, and should go in independent of the hugetlb support.
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> Thanks for your review,
>
> Alex

Hi Palmer,

I'm about to send the v2 for hugetlbfs support, do you want me to
merge this patch into it or do you prefer this patch to be separate ?

Thanks,

Alex

>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv