On Mon, Dec 26, 2016 at 04:53:39PM -0800, David Rientjes wrote: > > If there is really a need for an immediate solution^Wworkaround then I > > think that tweaking the madvise option should be reasonably safe. Admins > > are really prepared for stalls because they are explicitly opting in for > > madvise behavior and they will get a background compaction on top. This > > is a new behavior but I do not see how it would be harmful. If an > > excessive compaction is a problem then THP can be reduced to madvise > > only vmas. > > > > But, I really _do_ care about having a stall free option which is not a > > complete disable of the background compaction for THP. > > > > This is completely wrong. Before the "defer" option has been introduced, > we had "madvise" and should maintain its behavior as much as possible so > there are no surprises. We don't change behavior for a tunable out from > under existing users because you think you know better. With the new > "defer" option, we can make this a stronger variant of "madvise", which > Kirill acked, so that existing users of MADV_HUGEPAGE have no change in > behavior and we can configure whether we do direct or background > compaction for everybody else. If people don't want background > compaction, they can set defrag to "madvise". If they want it, they can > set it to "defer". It's very simple. > > That said, I simply don't have the time to continue in circular arguments > and would respectfully ask Andrew to apply this acked patch. +1. I don't see a point to make "defer" weaker than "madvise". MADV_HUGEPAGE is a way for an application to say that it's okay with paying price for huge page allocation. -- Kirill A. Shutemov -- 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>