I've been exercising the -proposed kernel all day on amd64 using stress- ng memory tests without any observed regressions.
Benchmark comparisons between the current -proposed kernel and the previous xenial kernel show that: 1. stream test: stream test (stress-ng): stress-ng --stream 1 --stream-l3-size 1M -t 60 --metrics-brief -v a 1% to 7% improvement on bogo stream ops per second with stream memory sizes ranging from 1M through to 512M. 2. malloc test: a 13-30% improvement on bogo malloc/free allocations (indirectly using mmap/munmap) for memory sizes ranging from 1M through to 1024M I believe this vindicates the default enabling of THP using enabled=madvise ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1703742 Title: Transparent hugepages should default to enabled=madvise Status in linux package in Ubuntu: Fix Released Status in linux-gke package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux-gke source package in Xenial: Fix Released Status in linux source package in Yakkety: Won't Fix Status in linux source package in Zesty: Won't Fix Status in linux source package in Artful: Fix Released Bug description: SRU Justification, Zesty, Xenial [Impact] Ubuntu kernels should default transparent_hugepages to enabled=madvise, not enabled=always (this corresponds to TRANSPARENT_HUGEPAGE_MADVISE=y in .config). I've blogged about this at some length here: https://blog.nelhage.com/post/transparent-hugepages/ but here is a summary: Transparent Hugepages are a feature that allows the kernel to attempt to automatically back any anonymous maps with "huge" 2MiB page tables, instead of the normal 4k entries. It can produce small net performance gains in certain benchmarks, but also has numerous downsides, in the form of apparent memory leaks and 30% slowdowns or worse for some applications. Many popular pieces of software now refuse to run with hugepages enabled because of known performance issues. Examples of problem reports: MongoDB: https://docs.mongodb.com/manual/tutorial/transparent-huge-pages/ Oracle: https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge Splunk: https://docs.splunk.com/Documentation/Splunk/6.5.2/ReleaseNotes/SplunkandTHP Go runtime: https://github.com/golang/go/issues/8832 jemalloc: https://blog.digitalocean.com/transparent-huge-pages-and-alternative-memory-allocators/ node.js: https://github.com/nodejs/node/issues/11077 Setting `enabled=madvise` enables applications that know they benefit from transparent huge pages to opt-in to this feature, while eliminating all the problematic behavior for other applications. Note also that transparent hugepage settings don't affect the use of explicit hugepages via hugetlbfs or mmap(…, MAP_HUGETLB, …) [Fix] Enable CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y [Regression Potential] May marginally impact performance, but the benefits of madvise'd huge transparent hugepage over-weigh this considerably. This has been enabled in Artful since July (and in Bionic) and we've not seen any regression reports, so we are confident this has minimal impact. [Testcase] Kernel ADT tests and stress-ng memory tests should not show any regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1703742/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
