Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred

From: Kirill A. Shutemov
Date: Mon Dec 26 2016 - 21:32:17 EST

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.


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