On Thu, 23 Feb 2012 14:56:36 -0500 Rik van Riel <riel@xxxxxxxxxx> wrote: > When we look for a VMA smaller than the cached_hole_size, we set the > starting search address to mm->mmap_base, to try and find our hole. > > However, even in the case where we fall through and found nothing at > the mm->free_area_cache, we still reset the search address to mm->mmap_base. > This bug results in quadratic behaviour, with observed mmap times of 0.4 > seconds for processes that have very fragmented memory. > > If there is no hole small enough for us to fit the VMA, and we have > no good spot for us right at mm->free_area_cache, we are much better > off continuing the search down from mm->free_area_cache, instead of > all the way from the top. This has been at least partially addressed in recent patches from Xiao Guangrong. Please review his five-patch series starting with "[PATCH 1/5] hugetlbfs: fix hugetlb_get_unmapped_area". I've already merged those patches and we need to work out what way to go. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>