From: David Rientjes <rientjes@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
mgorman@techsingularity.net, Vlastimil Babka <vbabka@suse.cz>,
mhocko@kernel.org, ying.huang@intel.com, s.priebe@profihost.ag,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
alex.williamson@redhat.com, lkp@01.org, kirill@shutemov.name,
Andrew Morton <akpm@linux-foundation.org>,
zi.yan@cs.rutgers.edu
Subject: Re: [patch v2 for-4.20] mm, thp: restore node-local hugepage allocations
Date: Thu, 6 Dec 2018 13:42:05 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.1812061341130.144733@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1812051445390.35948@chino.kir.corp.google.com>
On Wed, 5 Dec 2018, David Rientjes wrote:
> This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
> MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
> consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
>
> By not setting __GFP_THISNODE, applications can allocate remote hugepages
> when the local node is fragmented or low on memory when either the thp
> defrag setting is "always" or the vma has been madvised with
> MADV_HUGEPAGE.
>
> Remote access to hugepages often has much higher latency than local pages
> of the native page size. On Haswell, ac5b2c18911f was shown to have a
> 13.9% access regression after this commit for binaries that remap their
> text segment to be backed by transparent hugepages.
>
> The intent of ac5b2c18911f is to address an issue where a local node is
> low on memory or fragmented such that a hugepage cannot be allocated. In
> every scenario where this was described as a fix, there is abundant and
> unfragmented remote memory available to allocate from, even with a greater
> access latency.
>
> If remote memory is also low or fragmented, not setting __GFP_THISNODE was
> also measured on Haswell to have a 40% regression in allocation latency.
>
> Restore __GFP_THISNODE for thp allocations.
>
> Fixes: ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings")
> Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask")
> Signed-off-by: David Rientjes <rientjes@google.com>
We've identified a couple more regressions wrt 89c83fb539f9 ("mm, thp:
consolidate THP gfp handling into alloc_hugepage_direct_gfpmask") in
automated testing so I'm going to be proposing a full revert of that
commit for 4.20 as a follow-up to this.
next prev parent reply other threads:[~2018-12-06 21:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 22:46 [patch v2 for-4.20] mm, thp: restore node-local hugepage allocations David Rientjes
2018-12-06 4:59 ` [LKP] " kernel test robot
2018-12-06 21:42 ` David Rientjes [this message]
2018-12-06 22:00 ` [patch for-4.20] Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask" David Rientjes
2018-12-07 8:05 ` Michal Hocko
2018-12-07 23:05 ` David Rientjes
2018-12-10 8:34 ` Michal Hocko
2018-12-10 13:28 ` Kirill A. Shutemov
2018-12-07 14:41 ` Vlastimil Babka
2018-12-07 22:27 ` David Rientjes
2018-12-07 22:33 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1812061341130.144733@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=s.priebe@profihost.ag \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.com \
--cc=zi.yan@cs.rutgers.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).