linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: David Rientjes <rientjes@google.com>, Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Zi Yan <zi.yan@cs.rutgers.edu>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>,
	Stefan Priebe <s.priebe@profihost.ag>
Subject: Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
Date: Tue, 11 Sep 2018 10:51:12 +0200	[thread overview]
Message-ID: <21336327-2465-ba55-e721-4e48f782dff1@suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.21.1809101253080.177111@chino.kir.corp.google.com>

On 09/10/2018 10:08 PM, David Rientjes wrote:
> When Andrea brought this up, I suggested that the full solution would be a 
> MPOL_F_HUGEPAGE flag that could define thp allocation policy -- the added 

Can you elaborate on the semantics of this? You mean that a given vma
could now have two mempolicies, where one would be for hugepages only?
That's likely much more easy to suggest than to implement, with all uapi
consequences...

> benefit is that we could replace the thp "defrag" mode default by setting 
> this as part of default_policy.  Right now, MADV_HUGEPAGE users are 
> concerned about (1) getting thp when system-wide it is not default and (2) 
> additional fault latency when direct compaction is not default.  They are 
> not anticipating the degradation of remote access latency, so overloading 
> the meaning of the mode is probably not a good idea.
> 

  parent reply	other threads:[~2018-09-11  8:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 13:05 Michal Hocko
2018-09-08 18:52 ` Stefan Priebe - Profihost AG
2018-09-10  7:39   ` Michal Hocko
2018-09-11  9:03   ` Vlastimil Babka
2018-09-10 20:08 ` David Rientjes
2018-09-10 20:22   ` Stefan Priebe - Profihost AG
2018-09-11  8:51   ` Vlastimil Babka [this message]
2018-09-11 11:56   ` Michal Hocko
2018-09-11 20:30     ` David Rientjes
2018-09-12 12:05       ` Michal Hocko
2018-09-12 20:40         ` David Rientjes
2018-09-12 13:54     ` Andrea Arcangeli
2018-09-12 14:21       ` Michal Hocko
2018-09-12 15:25         ` Michal Hocko
  -- strict thread matches above, loose matches on Subject: below --
2018-08-23 10:52 [PATCH 2/2] mm: thp: fix transparent_hugepage/defrag = madvise || always Michal Hocko
2018-08-28  7:53 ` Michal Hocko
2018-08-28  8:18   ` Michal Hocko
     [not found]     ` <D5F4A33C-0A37-495C-9468-D6866A862097@cs.rutgers.edu>
2018-08-29 14:28       ` Michal Hocko
2018-08-29 14:35         ` Michal Hocko
2018-08-29 15:22           ` Zi Yan
2018-08-29 15:47             ` Michal Hocko
2018-08-29 16:06               ` Zi Yan
2018-08-29 16:25                 ` Michal Hocko
2018-08-29 19:24                   ` [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings Michal Hocko
2018-08-29 22:54                     ` Zi Yan
2018-08-30  7:00                       ` Michal Hocko
2018-08-30 13:22                         ` Zi Yan
2018-08-30 13:45                           ` Michal Hocko
2018-08-30 14:02                             ` Zi Yan
2018-08-30 16:19                               ` Stefan Priebe - Profihost AG
2018-08-30 16:40                               ` Michal Hocko
2018-09-05  3:44                                 ` Andrea Arcangeli
2018-09-05  7:08                                   ` Michal Hocko
2018-09-06 11:10                                     ` Vlastimil Babka
2018-09-06 11:16                                       ` Vlastimil Babka
2018-09-06 11:25                                         ` Michal Hocko
2018-09-06 12:35                                           ` Zi Yan
2018-09-06 10:59                       ` Vlastimil Babka
2018-09-06 11:17                         ` Zi Yan
2018-08-30  6:47                     ` Michal Hocko
2018-09-06 11:18                       ` Vlastimil Babka
2018-09-06 11:27                         ` Michal Hocko
2018-09-12 17:29                     ` Mel Gorman
2018-09-17  6:11                       ` Michal Hocko
2018-09-17  7:04                         ` Stefan Priebe - Profihost AG
2018-09-17  9:32                           ` Stefan Priebe - Profihost AG
2018-09-17 11:27                           ` Michal Hocko

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=21336327-2465-ba55-e721-4e48f782dff1@suse.cz \
    --to=vbabka@suse.cz \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.com \
    --cc=s.priebe@profihost.ag \
    --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