lkml.org 
[lkml]   [2016]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
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

\
 
 \ /
  Last update: 2016-12-27 03:32    [W:0.087 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site