archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <>
To: Rik van Riel <>
Cc: Hugh Dickins <>, Yu Xu <>,
	Andrew Morton <>,
	Mel Gorman <>,
	Andrea Arcangeli <>,
	Matthew Wilcox <>,
	Vlastimil Babka <>,
	"Kirill A. Shutemov" <>,,,
Subject: Re: [PATCH v2] mm,thp,shmem: limit shmem THP alloc gfp_mask
Date: Fri, 23 Oct 2020 10:49:56 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu 22-10-20 23:40:53, Rik van Riel wrote:
> On Thu, 2020-10-22 at 19:54 -0700, Hugh Dickins wrote:
> > But it's likely that they have accumulated some defrag wisdom, which
> > tmpfs can take on board - but please accept that in using a huge
> > mount,
> > the preference for huge has already been expressed, so I don't expect
> > anon THP alloc_hugepage_direct_gfpmask() choices will map one to one.
> In my mind, the huge= mount options for tmpfs corresponded
> to the "enabled" anon THP options, denoting a desired end
> state, not necessarily how much we will stall allocations
> to get there immediately.

It is really unfortunate that our configuration space is so huge and
messy but we have to live with that now.

Anyway, I would tend to agree that with an absense of per-mount defrag
configuration it makes sense to use the global one. Is anybody aware of
usecases where a mount specific configuration would make sense?
Michal Hocko

  reply	other threads:[~2020-10-23  8:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 16:45 [PATCH v2] mm,thp,shmem: limit shmem THP alloc gfp_mask Rik van Riel
2020-10-22 16:52 ` Vlastimil Babka
2020-10-23  2:54 ` Hugh Dickins
2020-10-23  3:40   ` Rik van Riel
2020-10-23  8:49     ` Michal Hocko [this message]
2020-10-23 12:55     ` Matthew Wilcox

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).