On Wed 28-12-16 13:33:49, David Rientjes wrote: > On Wed, 28 Dec 2016, Michal Hocko wrote: > > > I do care more about _users_ and their _experience_ than what > > application _writers_ think is the best. This is the whole point > > of giving the defrag tunable. madvise(MADV_HUGEPAGE) is just a hint to > > the system that using transparent hugepages is _preferable_, not > > mandatory. We have an option to allow stalls for those vmas to increase > > the allocation success rate. We also have tunable to completely ignore > > it. And we should also have an option to not stall. > > > > The application developer who uses madvise(MADV_HUGEPAGE) is doing so for > a reason. and nobody questions that... But the application developer can hardly forsee the environment where the application runs. And what might look as a reasonable cost/benefit balance in one setup can turn out completely wrong in a different one - just consider the fragmentation which is the primary contributor to stalls. It is hardly predictable and vary between different workloads/setups a lot. While we have a way (policty if you will) to tell that madvise should be honored as much as possible (defrag=madvise) we do not have a way to tell that even madvised vmas are not worth stalling over because the benefit would not offset the cost. > We lack the ability to defragment in the background for all users who > don't want to block while allowing madvise(MADV_HUGEPAGE) users to block, > as the changelog for this patch clearly indicates. And I agree that this is something to be addressed. I just disagree that this patch is the way how to achieve that. -- Michal Hocko SUSE Labs -- 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>