It builds both a process and threads based test in order to see any differences between the two. Test-description: Will It Scale takes a testcase and runs it from 1 through to n parallel copies to see if the testcase will scale. On test machine: 104 threads 2 sockets (Skylake) with 192G memory No idea about why the difference of the two path (VMA mergingįYI, we noticed a -21.1% regression of will-it-scale.per_thread_ops due to commit:Ĭommit: 0ba09b1733878afe838fe35c310715fda3d46428 ("Revert "mm: align larger anonymous mappings on THP boundaries"") The thp_get_unmapped_area() adds a padding to request mapping
If force to create new VMA with patch reverted, the result ofĤ. It looks like VMA merging introduce more latency comparing toģ. With the patch reverted, most VMA for 128 mapping can be merged. Before the patch reverted, almost all the VMA for 128M mappingĬan't be merged with prev/next VMA. The regression is related with the VMA merge with prev/nextĢ. "Yin, Fengwei" helped to check and got below clues:ġ. Recovered, but we observed another regression in mmap1 benchmark. When we tested the revert commit, the score in malloc1 benchmark Please note that we reported a regression in will-it-scale malloc1į35b5d7d676e ("mm: align larger anonymous mappings on THP Nathan reported a kbuild slowdown under clang toolchain commit was finally reverted.
Rik van Riel, Andrew Morton, Yang Shi, linux-kernel, linux-mm, 18:04 ` Yang Shi 0 siblings, 1 reply 9+ messages in threadįrom: kernel test robot 11:28 UTC ( / raw)Ĭc: oe-lkp, lkp, kernel test robot, Nathan Chancellor, Huang, Ying, 0ba09b1733: will-it-scale.per_thread_ops -21.1% regression in mmap1 benchmark archive mirror help / color / mirror / Atom feed * 0ba09b1733: will-it-scale.per_thread_ops -21.1% regression in mmap1 benchmark 11:28 kernel test robot
0 kommentar(er)
