On Tue, Feb 24, 2015 at 12:24:12PM +0100, Andrea Arcangeli wrote: > I would advise not to make changes for app that are already the > biggest users ever of hugetlbfs (like Oracle). Those already are > optimized by other means. THP target are apps that have several Before somebody risks to misunderstand perhaps I should clarify further: what I meant is that if the khugepaged boost helps Oracle or other heavy users of hugetlbfs, but it _hurts_ everything else as I'd guess, I'd advise against it. Because if an app can deal with hugetlbfs it's much simpler to optimize by other means and it's not the primary target of THP so the priority for THP default behavior should be biased towards those apps that can't easily fit into hugetlbfs and numa hard pins static placement models. Of course it'd be perfectly fine to make THP changes that helps even the biggest hugetlbfs users out there, as long as these changes don't hurt all other normal use cases (where THP is always guaranteed to provide a significant performance boost if enabled). Chances are the benchmarks are also comparing "hugetlbfs+THP" vs "hugetlbfs" without THP, and not "nothing" vs "THP". Clearly I'd like to optimize for all apps including the biggest hugetlbfs users, and this is why I'd like to optimize redis as well, considering it's simple enough to do it with just one madvise to change the behavior of COW faults and it'd be guaranteed not to hurt any other common usage. If we were to instead change the default behavior of COW faults we'd need first to collect data for a variety of apps and personally I doubt such a change would be a good universal tradeoff, while it's a fine change for a behavioral change through madvise. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>