• Adam Litke's avatar
    hugetlb: Try to grow hugetlb pool for MAP_PRIVATE mappings · 7893d1d5
    Adam Litke authored
    
    
    Because we overcommit hugepages for MAP_PRIVATE mappings, it is possible that
    the hugetlb pool will be exhausted or completely reserved when a hugepage is
    needed to satisfy a page fault.  Before killing the process in this situation,
    try to allocate a hugepage directly from the buddy allocator.
    
    The explicitly configured pool size becomes a low watermark.  When dynamically
    grown, the allocated huge pages are accounted as a surplus over the watermark.
     As huge pages are freed on a node, surplus pages are released to the buddy
    allocator so that the pool will shrink back to the watermark.
    
    Surplus accounting also allows for friendlier explicit pool resizing.  When
    shrinking a pool that is fully in-use, increase the surplus so pages will be
    returned to the buddy allocator as soon as they are freed.  When growing a
    pool that has a surplus, consume the surplus first and then allocate new
    pages.
    Signed-off-by: default avatarAdam Litke <agl@us.ibm.com>
    Signed-off-by: default avatarMel Gorman <mel@csn.ul.ie>
    Acked-by: default avatarAndy Whitcroft <apw@shadowen.org>
    Acked-by: default avatarDave McCracken <dave.mccracken@oracle.com>
    Cc: William Irwin <bill.irwin@oracle.com>
    Cc: David Gibson <david@gibson.dropbear.id.au>
    Cc: Ken Chen <kenchen@google.com>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    7893d1d5