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

From	"Kirill A. Shutemov" <kirill@shutemov.name>
Newsgroups	linux.kernel
Subject	Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
Date	2016-12-27 03:40 +0100
Message-ID	<sSPQd-4wp-5@gated-at.bofh.it> (permalink)
References	(4 earlier) <sRuXv-5wu-7@gated-at.bofh.it> <sRw3f-6bO-11@gated-at.bofh.it> <sRGP0-4vN-15@gated-at.bofh.it> <sSzs5-2Na-7@gated-at.bofh.it> <sSOhr-3wl-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Thread

[patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when  deferred David Rientjes <rientjes@google.com> - 2016-12-22 01:30 +0100
  Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-12-22 09:40 +0100
  Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-22 11:10 +0100
    Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-22 22:10 +0100
      Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-23 10:00 +0100
        Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-23 11:10 +0100
          Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-23 12:20 +0100
            Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-23 23:50 +0100
              Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-26 10:10 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-27 02:00 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-12-27 03:40 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-27 10:50 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-27 22:40 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-28 09:50 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-28 22:40 +0100
                Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-29 09:30 +0100
      Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Mel Gorman <mgorman@techsingularity.net> - 2016-12-30 13:40 +0100
        Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Michal Hocko <mhocko@kernel.org> - 2016-12-30 14:00 +0100
          Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Mel Gorman <mgorman@techsingularity.net> - 2016-12-30 15:10 +0100
        Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred David Rientjes <rientjes@google.com> - 2016-12-30 23:40 +0100
          Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Mel Gorman <mgorman@techsingularity.net> - 2017-01-03 11:40 +0100
  Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even  when deferred Vlastimil Babka <vbabka@suse.cz> - 2017-01-02 09:40 +0100

csiph-web