On Thu, Sep 03, 2020 at 01:57:54PM -0700, Mike Kravetz wrote: > On 9/3/20 9:25 AM, Roman Gushchin wrote: > > On Thu, Sep 03, 2020 at 09:32:54AM +0200, Michal Hocko wrote: > >> On Wed 02-09-20 14:06:12, Zi Yan wrote: > >>> From: Zi Yan <ziy@xxxxxxxxxx> > >>> > >>> Hi all, > >>> > >>> This patchset adds support for 1GB THP on x86_64. It is on top of > >>> v5.9-rc2-mmots-2020-08-25-21-13. > >>> > >>> 1GB THP is more flexible for reducing translation overhead and increasing the > >>> performance of applications with large memory footprint without application > >>> changes compared to hugetlb. > >> > >> Please be more specific about usecases. This better have some strong > >> ones because THP code is complex enough already to add on top solely > >> based on a generic TLB pressure easing. > > > > Hello, Michal! > > > > We at Facebook are using 1 GB hugetlbfs pages and are getting noticeable > > performance wins on some workloads. > > > > Historically we allocated gigantic pages at the boot time, but recently moved > > to cma-based dynamic approach. Still, hugetlbfs interface requires more management > > than we would like to do. 1 GB THP seems to be a better alternative. So I definitely > > see it as a very useful feature. > > > > Given the cost of an allocation, I'm slightly skeptical about an automatic > > heuristics-based approach, but if an application can explicitly mark target areas > > with madvise(), I don't see why it wouldn't work. > > > > In our case we'd like to have a reliable way to get 1 GB THPs at some point > > (usually at the start of an application), and transparently destroy them on > > the application exit. > > Hi Roman, > > In your current use case at Facebook, are you adding 1G hugetlb pages to > the hugetlb pool and then using them within applications? Or, are you > dynamically allocating them at fault time (hugetlb overcommit/surplus)? > > Latency time for use of such pages includes: > - Putting together 1G contiguous > - Clearing 1G memory > > In the 'allocation at fault time' mode you incur both costs at fault time. > If using pages from the pool, your only cost at fault time is clearing the > page. Hi Mike, We're using a pool. Under dynamic I mean that gigantic pages are not allocated at a boot time. Thanks!
