Messages in this thread |  | | Subject | Re: [PATCH v3 0/2] Hugetlbfs support for riscv | From | Alexandre Ghiti <> | Date | Thu, 4 Jul 2019 08:33:44 +0200 |
| |
On 7/4/19 12:57 AM, Paul Walmsley wrote: > Hi Alex, > > Thanks for writing and testing these patches, and thanks for your patience > waiting for reviews and testing.
No problem :)
> On Mon, 1 Jul 2019, 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. >> > [ ... ] > >> 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. > I was able to reproduce the 2MB megapages test results on rv64 QEMU. On a > HiFive Unleashed, though, a few more tests fail: > > - icache_hygiene fails ("icache unclean") > > # LD_LIBRARY_PATH=obj64 ./tests/obj64/icache-hygiene > Starting testcase "./tests/obj64/icache-hygiene", pid 732 > SIGILL at 0x15559fff80 (sig_expected=0x15559fff80) > SIGILL at 0x1555dfff80 (sig_expected=0x1555dfff80) > SIGILL at 0x15561fff80 (sig_expected=0x15561fff80) > SIGILL at 0x15565fff80 (sig_expected=0x15565fff80) > SIGILL at 0x15569fff80 (sig_expected=0x15569fff80) > SIGILL at 0x1556dfff80 (sig_expected=(nil)) > FAIL SIGILL somewhere unexpected > # > > - One of the heapshrink tests fails ("Heap did not shrink") > > # LD_PRELOAD="obj64/libhugetlbfs_privutils.so obj64/libhugetlbfs.so tests/obj64/libheapshrink.so" HUGETLB_MORECORE_SHRINK=yes HUGETLB_MORECORE=yes tests/obj64/heapshrink > Starting testcase "tests/obj64/heapshrink", pid 753 > FAIL Heap did not shrink > # > > Some of these may be related to the top-down mmap work, but there might be > more work to do on actual hardware.
I don't think this is related to top-down mmap layout, this test only mmaps a huge page. It might be interesting to see more verbose messages adding HUGETLB_VERBOSE=99 when launching the test.
> >> - 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. > I can reproduce some of these here on QEMU. But for reasons that are > unclear to me, 1G gigapages aren't working on the HiFive Unleashed here. > > In any case, these patches are clearly a good start, so I've queued > them for v5.3. > > > - Paul > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
|  |